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PREFACE 


This  Is  the  final  technical  report  for  a  LAN  Interoperability  Study 
conducted  for  the  Rome  Air  Development  Center  of  the  Air  Force  Systems  Command 
under  contract  F30602-83-C-0108.  The  study  Investigated  Issues  associated  with 
LAN-based  systems  protocols  needed  for  building  C3I  distributed  Information 
processing  systems.  The  study  spanned  over  12  months  and  devoted  3000 
professional  hours  of  study  effort. 

The  report  sets  forth  an  Introduction  to  the  compiled  material,  reviews 
some  background  of  the  problem,  sets  forth  what  the  study  objectives  were  and 
discusses  the  approach  taken.  A  comprehensive  discussion  of  the  results  Is  given 
followed  by  a  set  of  concise  conclusions.  Ten  recommendations  are  given,  providing 
a  roadmap  to  guide  the  Air  Force  In  developing  C3I  systems  and  LAN-based 
protocols.  Three  major  areas  are  Identified  where  future  work  Is  needed.  A  set 
of  protocols  and  design  approaches  for  Internetworking  Is  contained  In  a  set  of 
appendices. 

The  Principal  Investigator  and  Study  Meager  for  the  study  was  Walter 
L.  Elden.  The  leader  of  the  simulation  and  modeling  effort  was  Anita  L.  Miller. 

She  was  assisted  by  Susan  West  and  Sheila  Kasprzak.  Stephen  Morgan  contributed  to 
the  study  of  local  and  network  operating  systems.  Barbara  Romanzo  reviewed  the 
DOD's  high  level  protocols  and  TCP.  Or.  Peter  Knoke  contributed  In  reviewing  the 
NOS  and  DOS  forms  of  global  operating  systems.  Dave  Carson  provided  consulting 
advice  on  distributed  operating  systems.  William  Windham  contributed  to  the  early 
simulation  and  modeling  work.  Dr.  Larry  King  contributed  the  material  dealing 
with  multilevel  security  Issues. 

Mr.  Thomas  F.  Lawrence,  of  the  Distributed  Systems  Section,  C2 
Systems  Technology  Branch,  was  the  Contracting  Officer's  Technical  Representative 
during  the  course  of  the  study  contract. 
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SUMMARY 


The  LAN  Interoperability  Study  Final  Report  presents  the  results  of  a 

year  long,  3000  professional  study  hours,  Investigation  of  Issues  associated  with 

3 

Local  Area  Network  (LAN)  based  protocols  needed  for  C  I  distributed  processing. 

A  roaamap,  comprising  ten  recommendations,  three  major  areas  of  future  study  and 
eight  appendices,  sets  forth  a  plan  aimed  at  focusing  the  resources  of  the  Air 
Force  to  developing  distributed  processing  systems  for  the  1990's  C^I  programs. 

Distributed,  secure,  survlvable  Information  systems  are  needed  for  the 
strategic/tactical  battlefields  to  enable  Air  Force  personnel  to  maintain  control 
over  forces,  provide  Intelligence  about  enemy  intentions  and  capabilities,  warn  of 
attacks  or  hostile  actions,  help  conserve  resources  and  old  with  countless  other 
tasks.  The  key  to  achieving  these  capabilities  lies  In  applying  distributed 
systems  technologies  that  are  combi nable  to  create  an  Integrated,  system-wide 
command,  control,  communications  and  Intelligence  capability  (C  I). 

LAN-based  networking  protocols  will  be  needed  for  distributed 
information  processing  systems.  To  date,  which  ones  and  how  they  would  differ 
from  Wide  Area  Network  (WAN)  protocols  has  not  been  well  understood.  It  Is 
recognized,  though,  that  the  applications  environment  In  which  these  protocols 
will  be  employed  will  be  one  exhibiting  a  high  degree  of  heterogeneity.  The 
component  elements  (i.e.,  computers,  peripherals,  terminals),  the  end  system  as  a 
whole  and  the  LAN's  and  WAN's  will  probably  differ  In  their  architectures, 
interfaces  and  protocols. 

The  study  examined  distributed  processing  requirements  for  strategic 
and  tactical  C^I  systems,  reviewed  the  characteristics  and  architectural  Issues 
for  distributed  processing  global  operating  systems,  compared  the  DCD  and  ISO 
networking  protocol  architecture  models,  the  protocols  for  LAN's  developed  by  the 
IEEE  and  ANSI,  reviewed  and  conducted  performance  evaluation  of  Ethernet,  DOD's 
Internet  Protocol  and  Transmission  Control  Protocol  and  reported  characteristics 
of  CSMA/CD,  Token  Bus  and  Token  Ring  LAN's,  reviewed  three  alternatives  to  using 
TCP  for  an  intra-LAN  protocol  and  examined  the  methods  for  employing  gateway 
elements  to  interconnect  LAN-based  system  elements. 
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Th«  following  are  the  main  conclusions  reached  by  the  study: 

1.  C3  Bust  survive  and  offer  sufficient  flexibility  to  Identify, 
reconstitute,  and  employ  surviving  assets  for  trans-  and 

post-attack  command  ana  control. 

2 

2.  For  the  1990'$,  t*"t1cal  C  systems  will  need  to  be  Interoperable 
across  the  mllltai/  services  and  their  many  operational  and  support 
systems. 

3.  Currently,  use  of  OOP's  TCP  and  IP  protocols  appears  justified  to 
ensure  Interoperability  when  Interworking  through  wide  area 
networks.  Intra-LAN  use  needs  further  consideration. 

4.  The  International  Standards  Organization  work.  In  developing  the 
QSI/RM  and  Its  suite  of  protocols,  was  seen  as  the  key  Indicator  u f 
where  industry  was  going  with  protocols. 

5.  The  Air  Force's  Master  Plan  for  the  1990's  (TaFIIS)  calls  for  a 
dispersed,  distributed,  survlvable  C  system.  The  plan's  concept 
calls  for  configuration  In  a  distributed,  modular  architecture  with 
sharing  of  Information  seen  as  the  key  to  surveillance  and 
Intelligence  effectiveness. 

6.  CJ  needs  for  the  tactical  Army's  Air/Land  Battle  2000  system  are 
very  much  the  same  as  needed  for  the  Tactical  Air  Force. 

7.  Heterogeneous  processors  need  to  be  interoperable  over  networks, 
employing  high  level  protocols  and  packet-switching  to  achieve 
distributed  processing  for  C“I. 

6.  A  global  Network  Operating  System  (NOS)  or  Distributee  Operating 
System  (DOS)  form  of  high  level  operating  system  Is  required  to 
manage  the  distributed  system  resources.  The  NOS  form  builds  on 
top  of  the  original  heterogeneous  Constituent  or  Local  Operating 
System,  while  the  DOS  form  replaces  It  with  a  uni f cm  homogeneous 
global  one. 

9.  The  National  Software  Works  Implemented  ch®  NOS  form  on  top  of  the 
ARPANET  Wide  Area  Network. 

10.  The  CRONUS  DOS  Is  an  NOS  form  being  developed  to  work  on  top  of 
Local  Area  Networks. 

11.  A. Generic  Network  Operating  System,  callea  GNQS,  was  aeflned  and 
provides  a  general  reference  model  for  developing  protocols  for 
C3I  distributee  processing  systems. 
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12.  The  DOD  network  reference  model  provides  the  more  basic  networking 
utility  services/protocols,  whereas  the  ISO  set  is  more 
comprehensive  and  Is  directed  more  formally  to  apply  object-based 
design  for  future  distributed  processing  applications. 

13.  The  IEEE  602  Project  has  developed  the  currently  leading  industry 
protocols  for  LAN's,  operating  at  10  Mb/s. 

14.  ANSI  X3T95  Is  developing  a  fiber-optic-baseo  Token  Ring  LAN 
operating  at  100  Mb/s. 

15.  The  Air  Force  Is  developing  the  Flexible  Intraconnect  LAN  (FILAN) 
to  operate  at  180  Mp/s  and  be  used  in  C^I  systems. 

16.  Based  on  analysis,  the  CSMA/CO  offers  an  acceptable  contention 
scheme  for  light  to  moderate  loads  while  the  Token  Access  Methods 
do  for  the  deterministic  approach,  when  moderate  to  heavy  loads  and 
controlled  delay  are  criteria. 

17.  Simulation  results  Indicated  that  throughputs  up  to  5  Mb/s  were 
obtained  for  a  single  TCP  connection  on  Ethernet  (10  Mp/s)  with  no 
collision  occurring  and  that  protocol  processing  times  contributed 
more  to  performance  than  did  protocol  overhead  at  the  cable  level. 

16.  Three  alternatives  to  TCP  for  Intra-LAN  use  were  1)  extended 
backplane,  2)  subset  of  TCP,  and  3)  a  null  layer. 

19.  A  family  of  gateway  elements  used  with  open  protocols  was 
Identified  to  achieve  LAN-based  systems  Interoperability. 

Ten  recommendations  are  made  which  provide  the  Air  Force  a  roadmap  for 
developing  C^I  distributed  systems  for  the  l?9Q's.  Areas  of  future  study  are 
given  and  key  protocols  and  Internetworking/Interoperability  design  approaches  are 
presented  In  a  set  of  appendices.  The  main  thrusts  of  the  recommendations  are  as 
follows: 

3 

1.  Forming  a  joint  Air  Force-Industry  C  I  protocol  development 
effort. 

2.  Developing  a  layered  reference  model  for  C^I  applications  and 
systems. 

3.  Employing  the  Generic  Network  Operating  System  (GMOS)  to  guide 
development  of  networking  protocols  for  CJI. 

4.  Employment  of  gateway  elements  and  GNUS  protocols  to  achieve 
LAN-based  systems  Interoperability- 

5.  Need  for  different  intra-LAN  and  Inter-LAN  protocols  for  the 
underlying  transport  services. 
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6.  Use  of  Multiple  LAN's  to  meet  application  requirements. 

7.  Continuing  research  Into  protocol  design,  validation  and  formal 
verification  methods. 

8.  Need  for  a  design  practices  handbook  for  quantifying  LAN 
performance  characteristics. 

9.  Need  to  evaluate  performance  of  high  level,  multiple  LAN's  and  WAN 
protocols  through  simulation  and  modeling. 

10.  Need  to  study  further  the  areas  of: 

a.  Distributed  Systems  Design  Issues 

b.  Integrated  OSI  for  Distributed  Information  Processing 

c.  Multilevel  Secure  Distributed  Operating  System  Issues 
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INTRODUCTION 

Statement  of  the  Problem 


Distributed,  secure,  survlvable  Information  systems  are  needl'd  for  the 
strategic/tactical  battlefields  to  enable  Air  Force  personnel  to  maintain  control 
over  forces,  provide  intelligence  about  enemy  intentions  and  capabilities,  warn  of 
attacks  or  hostile  actions,  help  conserve  resources  and  aid  with  countless  other 
tasks.  The  key  to  achieving  these  capabilities  lies  In  applying  distributed 
systems  technologies  that  are  combinable  to  create  an  Integrated,  system-wide 
command,  control,  communications  and  Intelligence  capability  (C^I). 

The  major  technologies  needed  for  distributed  C^I  comprise 
distributed  processing,  distributed  data  base  management,  distributed  network-wide 
operating  system(s),  multilevel  security,  mixed-media  data  conmunlcatlons,  a  suite 
of  networking  protocols  (applications  utilities,  host-to-host  and  subnetl, 
internetworking  gateways,  wide  and  local  area  networks  (WAN's  and  LAN's).  LAN's 
are  new  high-speed  (1-200  Mb/s)  bus  or  ring  topology  digital  comnunJ cation 
networks  which  provide  shared  communication  capacity  for  a  localized  area  of 
coverage.  Some  of  these  needed  technologies  have  been  developed  for  systems 
distributed  over  wide  area  networks,  like  the  ARPANET  and  the  National  Software 
Works.  However,  newer  local  area  network  technologies  are  just  emerging,  have  a 
number  of  different  architectures  and  protocols  and  exhibit  considerably  Improved 
performance/cost  characteristics.  It  Is  not  well  understood  to  what  extent 
solutions  developed  for  wide  geographic  area  networks  are  suitable  for  the  newer 
local  area  networks  and  the  new  distributed  network-wide  operating  systems  to  be 
used  with  them. 

LAN-based  networking  protocols  will  be  needed  for  distributed 
Information  processing  systems.  To  date,  which  ones  and  how  they  would  differ 
from  the  WAN  protocols  has  not  been  well  understood.  It  is  recognized,  though, 
that  the  applications  environment  in  which  these  protocols  will  be  employed  will 
be  one  exhibiting  a  high  degree  of  heterogeneity.  The  component  elements  ( 1 .e. , 
computers,  peripherals,  terminals),  the  end  systems  as  a  whole  and  the  LAN's  and 
WAN's  will  probably  differ  in  their  architectures.  Interfaces  and  protocols. 

New  technology  research  and  development  Is  being  pursued  by  the  Air 
Force  in  many  facets  of  distributed  processing,  such  as  artificial  Intelligence 
and  expert  systems,  distributed  data  base  management,  distributed  network-wide 
operating  system,  multilevel  security,  networking  protocols,  LAN's,  WAN's  and 
mixed-media  for  LAN's.  In  order  to  be  able  to  Integrate  these  Individual 
technologies  together  into  a  cohesive  system,  the  Air  Force  needs  a  roadmap  to 
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guide  this  process.  This  roadmap  should  address  objectives,  services,  functions, 
architecture,  protocols  and  eventual  military  standards  spanning  the  distributed 
C^I  battlefield  systems  needs.  The  study  and  Investigation  reported  on  herein 
for  LAN  Interoperability  has  examined  many  of  the  Issues  raised  above  and  presents 
its  results,  conclusions,  recommendations  and  Identifies  areas  needing  further 
study  and  development. 
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SECTION  2.0 
BACKGROUND 


2.0 


BACKGROUND 

8ackgound  of  the  Problem 


Improving  price-performance  availability  of  microprocessors,  semi  and 
custom  high  density  VLSI  devices,  and  high-speed  local  area  networks  (LAN's)  will 
enable  building  new  Information  systems  which  may  be  functionally  distributed  In 
new  C  applications.  These  systems  will  need  to  be  made  secure.  Interoperable 
and  survlvable  in  both  strategic  and  tactical  deployments. 

Clusters  of  data  processing  resources  may  comprise  an  oi'ganlzatlon* s 
subsystem,  configured  to  perform  strategic  or  tactical  command  and  control 
operations.  This  Is  demonstrated  by  Figure  2.0.  These  clusters  can  consist  of 
varying  types  of  computers  with  different  operating  system  software.  Further,  new 
high-speed,  low  error  rate,  low  delay  and  high  reliability  LAN's  will  make 
possible  the  Interconnecting  together  of  these  data  processing  resources  In  single 
and  dispersed  cluster  (Intra-LAN)  and  multiple  localized  cluster  (Inter-LAN) 
configurations.  Through  the  use  of  a  distributed  network-wide  operating  system 
and  Its  companion  high  level  application  processing  protocols,  these  dispersed 
data  processing  subsystems  will  be  able  to  be  integrated  Into  one  coherent, 
responsive  and  reliable  system. 

The  LAN's  which  might  be  utilized  to  construct  a  distributed  system  for 
C2  today  vary  considerably  In  the  service  provided,  functions  performed,  their 
archl tecture ,  protocols  employed,  media,  topology  and  media  access  control  methods 
utilized  and  performance.  In  other  words,  LAN's  are  very  heterogeneous. 

Some  LAN's  employ  twisted-pair,  coaxial  or  fiber-optic  media.  Either 
baseband  (single)  or  broadband  (multiple)  channelization  Is  employed.  The  media 
access  method  can  be  Carrier  Sensed  Multiple  Access  (with  or  without  Collision 
Detection),  Token  Bus  or  Token  Ring  protocols.  LAN's  are  characterized  by  their 
limited  diameter  of  connectivity  (maximum  about  10  kilometers),  by  their  very  low 
transmission  delay  (less  than  1  microsecond  per  bit)  and  high  transmission  speed 
(1-200  Mb/s). 

LAN's  can  provide  variable  high  throughput  -  low  delay,  low  error  rate 

and  direct  peer-to-peer  communications  In  the  local  area.  For  the  most  part,  most 

communications  traffic  will  originate  and  terminate  within  the  same  LAN  between 

resources  distributed  on  It.  However,  some  traffic  will  need  to  leave  an 

originating  LAN  and  terminate  on  another  LAN.  Though  physical  connectivity  can  be 

2 

achieved  through  the  use  of  a  LAN,  an  Integrated  C  system  at  a  functional  level 
requires  a  suite  of  protocols,  most  residing  above  the  LAN's  Dhyslcal  media  access 
protocol  level. 
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Figure  2.0.  LAN-Based  Distributed  Comnand 
and  Control  Network  Model  Problem  Investigated 

In  addition  to  the  LAN  transmission  protocols,  the  following  examples 
of  higher  level  protocols  will  also  be  needed: 

•  Host-to-host  Interprocess  communications 
File  access  and  transfer 

•  Terminal  handling 

•  Data  base  access  and  update 

•  Message  transfer 

•  Process-to-process 

•  Resource  monitoring  and  management 
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•  System  fault  tolerance/survivability 

•  Interactive  access  to  distributed  processer 

•  Internetworking  (via  gateways) 

Collectively,  these  protocols  will  constitute  the  procedures  or  rules 
by  which  the  various  dispersed  logical  elements  of  the  system  coordinate  their 
respective  activities  to  achieve  each  of  the  following  objectives: 

•  Interoperability  among  heterogeneous  processing  elements  within  a 
given  LAM 

•  Interoperability  among  LAM-based  systems,  each  using  different 
protocols  at  all  levels  of  abstraction 

•  Security  of  Information 

•  Survivability  of  system  functionality 

•  System-wide  control  of  data  processing  and  communication  resources 

Geographically  dispersed  systems,  such  as  the  ARPANET  [1]  and  the 

Defense  Data  Network  [2]  have  developed  and  todey  employ  protocols  which  perform 
many  of  the  functions  discussed  above.  Those  wide  area  networks  (WAN’s)  and  the 
local  area  networks  (LAN’s)  of  Interest  for  distributed  C2  applications  vary 
widely  In  their  characteristics  [3,  4],  It  was  not  clear  If  these  protocols  would 
be  adequate  (that  Is,  represent  an  efficient  Implementation  choice)  for  LAN-based 
C2  systems.  Further,  It  was  expected  that  subfunctions  within  an  organization 
would  each  be  Implemented  on  contiguous  but  different  LAN-jased  systems. 

Protocol  layered  networking  architectures,  such  as  the  Open  Systems 
Interconnection  Reference  Model  (OSI/RM)  of  the  International  Standards 
Organization  (ISO)  [5],  provide  a  formal  type  of  high  level  abstraction  for 
defining  protocols.  It  was  not  known  whether  the  OSI/RM’s  layered  protocol 
structuring  contained  the  appropriate  functional  definitions  within  Its  layers  for 
a  LAN-based  C2  system  to  achieve  efficient  and  effective  LAN  Interoperability. 

The  following  are  major  issues  Involved  with  building  distributed 
Information  processing  systems  and  do  not  have  satisfactory  protocol  solutions  yet: 

•  How  to  make  high  level  applications  interoperate  compatibly 

•  What  protocols  are  needed  to  support  high  level  applications 

•  Interoperability  among  LAN-based  heterogeneous  processing  elements 

•  Interoperability  among  heterogeneous  LAN-based  systems 
Internetworked  together 

•  System-wide  control  of  data  and  communications  processing 

•  Multilevel  security  and  Interprocess  communications  encryption 

•  Survivability 
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•  Standardized  H/w  and  S/W  modular  elements 

•  Subdivision  of  C2  functions  Into  $ubfunct*ons  distributed  over 
LAN-based  processors 

•  Information  sharing 

•  Directory  services  of  physical /logical  objects  and  resources 

•  Task  scheduling 

•  LAN-based  MININET  COS  *  (MINIDOS) 

•  WAN-based  MAXI NET  DOS  *  (MAXIDOS) 

•  Cooperating  processing 

a  Device  transparency 

*D0S  denotes  Distributed  Operating  System 

The  study  report’s  title,  "LAN  Interoperability,"  tends  to 
overemphasize  the  focus  which  the  study  conducted.  While  It  was  recognized, 
through  close  liaison  with  che  study's  Contracting  Officer  Technical 
Representative  (COTR),  that  LAN's  were  to  be  the  Intended  data  communcatl ons 
subnetworks  for  C2  systems,  the  resultant  study's  focus  was  steered  to  be  placed 
upon  the  information  processing  user  elements  vrfilch  would  be  attached  to  a  LAN. 
These  LAN  users  comprise  the  higher  layers  of  networking  protocols  and  the 
functions  comprising  a  distributed  network-wide  operating  system.  It  Is  within 
these  protocol  layers  where  such  networking  utility  services  as  file  transfer, 
terminal  handling,  message  exchange  and  remote  Job  processing  are  performed  by 
virtual  protocols.  Exactly  how  and  where  these  networking  utility  protocols 
Interface  with  the  distributed  network-wide  operating  system  has  not  been 
understood  and  constituted  one  of  the  major  study  Issues. 

With  the  OOD  having  Its  ARPANET-based  networking  architecture/protocols 
and  the  ISO  having  its  own  OSI/RM  archltecture/protocols,  an  Issue  existed  at  the 
start  of  the  study  relative  to  whether  one,  the  other  or  both  protocol  suites 
would  predominate.  More  specifically,  a  question  had  been  raised  relative  to  the 
continued  use  by  the  DOD  of  Its  Transmission  Control  Protocol  (called  TCP)  along 
with  the  Internet  Protocol  (IP).  An  alternative  cited  was  the  National  Bureau  of 
Standards  Transport  Protocol  (Class  4),  referred  to  as  TP4.  Further,  while  the 
000  had  Issued  a  directive  [6]  making  use  of  the  TCP/IP  protocols  mandatory  for 
use  with  wide  area  networks,  the  Air  Force,  by  the  start  of  the  study,  had  gore 
further  by  setting  a  policy  [7]  requiring  use  of  TCP/IP  within  local  area  networks 
as  well. 

Several  study  reports  and  papers  [4,  8,  9]  had  proposed  alternatives  to 
the  use  of  full  TCP/IP  in  a  LAN  prior  to  the  start  of  the  study.  The  need  existed 
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to  establish  an  objective  quantitative  set  of  data  which  would  set  out  the 
performance  capabilities  achievable  using  TCP/IP  In  a  LAh.  as  a  basis  for 
technically  assessing  the  Impact  of  complying  with  the  policy  directives  Issued  by 

the  Air  Force. 

The  remaining  study  report  discusses  the  above  Issues  In  light  of  the 
study's  objectives,  methodology/slmulatlons  employed,  results  achieved, 
conclusions  drawn,  recommendations  made  and  areas  identified  needing  further  study. 
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3.0 


STUOY  OBJECTIVES 
General 


At  the  outset,  the  Statement  of  Work's  long-term  objectives  of  the 
study  were  to  achieve  the  following  within  the  constraints  of  the  level  of  effort 
contracted  for: 

1.  Develop  protocols  to  support  efficient  and  effective  conmunl cation 
among  application  level  processes  within  a  Local  Area  Network  (LAN) 

2.  To  Investigate  the  Issues  associated  with  Interoperability  among 
LAN's  based  on  differing  protocols  of  the  transmission  through 
application  levels 

3.1  Initial  Study  Investigation  Objectives 

The  proposed  Investigation  objectives  were  structured  to  focus  on  the 
Interprocess  communications  protocols  needed  to  support  higher  level  application 
layer  protocols.  In  particular,  the  primary  candidate  protocol  for  consideration 
was  the  Transmission  Control  Protocol /Internet  Protocol  pair  of  the  DOD,  In  the 
context  of  the  IEEE  802  CSMA/CD,  Token  Bus  and  Token  Ring  suite  of  LAN  protocols. 

The  following  Initial  study  objectives  were  Identified  to  be  the  major 
areas  to  be  Investigated: 

•  Selection  of  baseline  command  and  control  system  models  for  the 
Intra-LAN  (clustered  MINIDOS)  and  Inter-Lan  (cluster-to-cluster 
MAXIDOS)  configurations 

•  Establishment  of  representative  data  processing  equipment/LAN 
configurations,  topologies,  functions  and  work  loads  within  these 
two  configurations 

•  Review  of  candidate  network  architecture,  services,  functions  and 
protocols  needed  to  support  the  Distributed  Operating  System  (DOS) 
high  level  application  protocols  and  gateways 

•  Conducting  of  a  series  of  studies  focussing  on  a  localized 
Intra-LAN  configuration  for  the  MINIDOS 

•  Conducting  of  a  series  of  studies,  focusing  on  a  localized  set  of 
LAN's  Interconnected  for  the  MAXIDOS 

•  Configuring  and  utilization  of  a  simulation  model  to  enable 
conducting  analysis  of  four  alternative  TCP/IP  protocol  approaches 
and  combinations  of  commercial  /militarized  LAN  subnets 

•  Review  of  the  approach  taken  In  the  Multi net  Gateway  design  and 
assessing  how  the  LAN  to  Multi net  Interconnect  should  be  done 
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•  Developing  of  protocols  and  design  approach  recommendations 

reporting  on  findings  from  Investigating  tne  following  specific 

Issues : 

Intra-LAN  Interoperabil ity  (HINIDOS  Configuration) 

•  Suitability  of  ARPANET  protocols 

•  How  LAN  characteristics  affect  application  level  protocols 

•  Performance  effects  of  LAN  features  on  application  level 
protocol s 

Inter-LAN  Interoperability  (MAXIDOS  Configuration) 

•  Multiple  LAN's  employing  different  protocols 

•  Suitability  of  WAN  gateways  to  LAN's 

•  Interprocess  conminl  cations  between  different  host-to-host 
protocol s 

Figures  3.1-1  through  3.1-4  Illustrate  the  MINIDOS  and  MAXIDOS  models 
of  Intra-LAN  and  Inter-LAN  configurations  and  the  suite  of  protocols  associated 
with  the  TCP/IP  Interprocess  communications  protocols  of  Interest. 

3.2  Revised  Study  Investigation  Objectives 

Midway  through  conduct  of  the  study,  the  emphasis  was  shifted  away  *ra 
TCP/IP  Interprocess  communications  and  detailed  performance  simulation  of  mult1p1< 
LAN  protocols  to  focusing  upon  the  higher  layer  protocol  Issues.  This  occurred 
after  a  6-month  review  of  the  progress  made  to  that  point. 

The  revised  plan  shifted  the  study  resources  away  from  the  underlying 
LAN  communications  protocols  (layers  1-4)  and  gave  primary  attention  to  the 
information  processing  region.  That  Is  whe-e  the  higher  layers  of  protocols 
(layers  5-7)  need  to  become  Integrated  Into  the  distributed  operating  systems 
functions  to  enable  building  distributed  c-.:  r.-f  and  control  applications 
processing  support  services. 

To  enable  a  more  top  down  systems  '.‘riven  approach,  several  tactical  an 

one  strategic  command  and  control  systems  studies  p*ev1ously  conducted  on 

requirements  and  architectures  were  to  be  Investigated  covering  the  tactical  Air 

Force,  Army  and  strategic  DCA  missions,  ‘text,  conventional  and  distributed 

operating  systems  needed  to  support  the  C"  mission  systems  >ore  to  be  thoroughly 

studied.  The  objective  here  was  to  examine  and  establish  the  structures,  major 

subsystems,  services,  functions,  protocols,  mechanisms  and  Issue:  necessary  to 
2 

support  C  systems. 
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Protocol  Hierarchy  Eopioylng  TCP/IP 


Another  objective  was  to  concentrate  primarily  on  the  LAN-based 
distributed  network  operating  system  and  Its  Interface  to  the  localized  operating 
system:  the  HINILOS  and  COS. 

Additional  objectives  in  the  revised  study  were  the  following: 

•  Review  of  ARPANET  higher  layer  protocols,  the  DOD  TCP/IP  protocols 

anG  the  ISO  Open  Systems  Interconnection  protocols,  to  determine 

2 

suitability  to  satisfying  the  C  and  DOS  requirements 

•  Narrowing  of  the  simulation/modeling  work  to  utilize  only  an 
Ethernet  LAN  with  TCP/IP  and  possibly  higher  layer  DOD  protocols 

•  Investigation  of  internetworking  issues  associated  with  Joining 
LAN‘s  to  each  other  directly  and  by  way  of  a  WAN 

Since  the  revised  LAN  study  contract  resources  would  not  support 

protocol  development  under  the  revised  study  scope,  the  Identification  of  needed 

2 

C  protocols,  services,  functions  and  interface/peer  protocol  state  machines  was 
to  be  the  primary  objective.  Greater  emphasis  was  to  be  given  to  Identifying  what 
the  issues  were,  which  protocols  were  needed  and  what  new  technology  projects 
needed  to  be  initiated,  so  as  to  provide  the  Air  Force  a  roadmap  to  guide  Its 
technology  developments. 
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4.0 


STUDY  APPROACH 
Overvl ew 


The  study  dealt  with  policies,  requirements,  architectures,  protocols 
and  technologies,  which  spanned  all  layers  of  the  Department  of  Defense's  and  Open 
Systems  Interconnection  Reference  Models.  Additional  systems  aspects  went  beyond 
those,  reaching  Into  the  heart  of  command  and  control  systems  services,  functions 
and  characterises  and  those  of  distributed  processing  and  operating  systems. 

The  early  Investigations,  spanning  the  first  6  months,  primarily 
focused  on  structuring  the  simulation  model  for  later  evaluation  of  the  IEEE  802 
LAN  protocols  for  Layers  0,  1  and  2,  plus  the  DOD's  TCP  and  IP.  At  the  same  time, 
review  of  DOD  and  Air  Force  policies  and  architectures  for  protocols  was  made. 

The  second  half  of  the  study  took  a  mere  top  down  systems  approach,  starting  with 
representative  Command  and  Control  requirements  leading  to  examination  of 
distributed  network  operating  systems  and  the  high  layer  application  support 
virtual  service  protocols.  Simulations  of  TCP/IP  and  measurement  data  later  was 
obtained.  Generic  gateways  and  bridges  needed  for  Interconnections  were  studied. 

4.1  Assessment  of  OOP,  Air  Force  and  Industry  Directions 

This  part  of  the  study  was  an  ongoing  effort  to  become  Informed  of  and 
to  keep  apprised  of  the  policies,  architectures  and  protocols  likely  to  become  the 
standards  of  the  overall  networking  Industry  groups.  At  the  start  of  the  study. 

It  was  apparent  that  a  clear  consensus  of  agreement  did  not  then  exist  among 
elements  of  the  DOD,  Air  Force  and  Industry,  regarding  a  common  architecture  and 
the  Individual  protocols  to  be  employed. 

4.1.1  Department  of  Defense  Direction 

Officials  within  the  DOD's  Defense  Communication  Agency  (DCA)  were 
contacted  and  liaison  established  during  the  term  of  the  study.  The  DCA  Is  the 
DOD's  Executive  Agent  for  the  development  of  protocol  standards  and  has  done 
considerable  work  on  the  Transmission  Control  and  Internet  Protocols  (TCP/IP) 

[10].  In  particular,  representatives  of  the  DOD's  Protocol  Standardization 
Program  [11]  and  protocol  development  work  were  contacted  from  time  to  time.  This 
enabled  the  study  to  gain  access  to  ongoing  work  and  issues  with  which  those 
bodies  were  dealing. 

Separate  contact  was  established  with  the  ARPANET'S  Network  Information 
Center  and  several  sets  of  the  ARPANET  Internet  suite  of  protocols  were  obtained 
[1]. 
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To  assist  further  In  a  better  understanding  of  the  ARPANET  protocols, 
two  members  of  the  study  attended  a  1-week  course  on  the  000  Internet  Protocols. 
This  was  given  by  the  George  Washington  University  and  was  taught  by  Dr.  David 
Mills,  one  of  the  architects  of  the  Internet  protocol  suite. 

About  the  time  of  the  start  of  the  LAN  study,  an  Inquiry  had  begun  over 
the  Issue  of  whether  the  000' s  TCP  protocol  should  be  continued  to  be  used  or 
replaced  by  one  developed  by  the  National  Bureau  of  Standards  (NBS).  The  NBS  had 
developed  a  Transport  Protocol  which  conformed  to  the  Class  4  protocol  of  the  ISO 
and  was  known  as  TP4.  The  Inquiry  was  assigned  to  be  conducted  under  the  National 
Research  Council  of  the  National  Academies  of  Science  and  Engineering.  Liaison 
was  established  and  maintained  on  an  ongoing  basis  with  the  administrative  office 
of  the  National  Research  Council  during  the  study*  It  was  felt  that  the  outcome 
of  this  Inquiry  might  have  a  profound  Impact  on  the  future  course  of  the  DOO's 
protocol  standardization  effort,  and  on  TCP/IP  and  higher  layer  protocols  In 
particular. 

4.1.2  Air  Force  Direction 

At  the  start  of  the  study,  a  member  of  the  Air  Force  Communications 
Command  (AFCC)  Informed  Harris  study  members  that  the  Air  Force's  Air  Staff 
responsible  for  LAN's  had  formulated  a  new  policy  that  "the  DOD's  TCP/IP  protocols 
are  the  Air  Force  standards  for  connection-based  transport  and  Internetwork 
services  within  packet-oriented  local  area  networks"  [12,  13].  As  a  result, 
liaison  was  established  with  members  of  the  Air  Force's  LAN  Air  Staff  office  who 
were  consulted  periodically  to  ascertain  the  Air  Force’s  Intent  and  further 
policies.  A  draft  LAN  architecture  document  [13]  provided  more  detailed  technical 
Insight  regarding  this  policy. 

A  new  Systems  Program  Office  for  Air  Force  LAN's  (AFLAN  SPO)  was 
established  during  the  conduct  of  the  study.  The  Director  of  the  office  was  met 
and  Informed  about  the  LAN  study's  Intended  objectives.  The  study  team  was  of  the 
opinion  that  continuing  contact  with  this  office  was  appropriate  since  the 
recommendations  the  study  team  might  make  would  possibly  have  significant  Impact 
on  LAN  protocols  and  architecture  which  could  affect  their  use  in  Command  and 
Control  applications. 

To  assist  the  study  team  In  keeping  apprised  of  Air  Force  efforts  In 
developing  LAN  technology,  attendance  was  made  at  a  2-day  workshop  on  the  Flexible 
Intraconnect  LAN.  This  was  arranged  by  the  Air  Force's  RADC  FILAN  Program 
Office.  The  current  status  of  the  FILAN  development,  capabilities  and  future 
directions  were  learned. 
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4.1.3  Industry  Directions 

The  primary  sources  used  for  assessing  the  direction  of  industry  were 
the  International  and  national  standards-maklng  bodies  as  well  as  selected  vendor 
product  offerings  for  networking.  The  ongoing  work  projects  Involved  In 
developing  the  overall  architecture  and  Individual  protocol  standards  for  the  Open 
Systems  Interconnection  Reference  Model  (OSI/RM)  [14-18]  were  the  major 
indicators  used  to  gauge  where  “Industry"  was  going.  The  joint  agreement  by  the 
CCITT  and  ISO  standards-maklng  bodies  on  a  single  standard  for  the  OSI/RM  occurred 
during  the  study  period  and  set  a  firm  direction  of  the  International  community  on 


that  Issue. 

During  the  course  of  the  study,  attendance  was  made  at  meetings  of  the 
IEEE  802  LAN  project  as  well  as  the  ANSI  X3T55  High  Level  Protocols  to  assess 
firsthand  their  work  and  Its  possible  Implications  for  the  Issues  being  studied. 
Various  draft  protocol  documents  ard  working  papers  were  also  obtained  as  they 
were  considered  of  relevance  to  the  study.  Overall,  references  [14,  15]  were 

considered  the  best  gauge  of  Industry  direction. 

Various  LAN  product  offerings  by  manufacturers  were  monitored  and 


reviewed  to  ascertain  possible  significant  Impact  on  future  networking 
directions.  In  particular,  the  architecture  and  product  developments  reported 
unoer  way  by  IBM  In  Its  Systems  Network  Architecture  [19],  Its  SNA-to-OSI 
internetworking  [20]  and  Its  Token  Ring  LAN  [21]  were  considered  the  most 
significant  Indicators.  In  particular,  IBM's  revealing  that  Its  newest  additions 
to  its  SNA  [19]  constituted  a  Distributed  Operating  System  and  Its  embracing  cf 
the  Open  Systems  Interconnection  architecture  and  protocols  [20]  as  the  way  It 
will  enable  building  global  heterogeneous  network  were  considered  extremely 


relevant  to  the  study's  main  area  of  concern. 

A  1-day  seminar  on  the  LAN  products  offered  by  Network  Systems 

Corporation  was  attended.  This  covered  NSC's  Hyperchannel,  Hyperbus  and  Netex.  A 
half-day  work  session  was  held  with  the  Program  Manager  of  the  Multlnet  Gateway 
product  development  with  Ford-Aerospace.  This  provided  architectural  and 
Interface  technical  data  to  the  study  team  of  that  ongoing  RADC-sponsored  effort. 

The  study's  Principal  Investigator,  M*\  Walter  L.  El  den,  was  Chairman 
of  the  Avionics  High-Speed  Data  Bus  Applications  and  Requirements  Task  Group 
(HART)  of  this  SAE-AE9B  Subcommittee.  A  recommendation  was  made  to  develop  the 
next  generation  avionics  LAN  based  on  the  IEEE  802  Token  Ring  LAN  using 
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fiber-optic  cable,  operating  In  the  50-200  Mb/s.  This,  along  with  IBM's  announced 
plan  to  offer  a  Token  Ring  LAN,  gave  Indication  that  for  the  longer  term,  the 
Token  Ring  LAN  might  become  dominant. 

4.2  Tactical  Command  and  Control  System  Models  and  Requirements 
Command  and  Control  was  considered  from  both  a  strategic  and  tactical 

frame  of  reference.  Available  documentation  was  more  readily  obtainable  for  the 
tactical  deployments  to  control  Air  Force  air-ground  resources  and  planned  Army 
ground  resources.  However,  the  primary  references  employed  were  [22,  23,  24]. 

[22,  23]  covered  Air  Force  models,  requirements  and  recommended  architectures  and 
[24]  focused  on  an  Army  system  architecture  for  the  electronic  battlefield. 

In  each  of  these  references,  the  following  characterizations  were 
examined  and  common  relationships  extracted  to  provide  a  profile  to  drive  the 
succeeding  studies  from  the  top  down: 

•  Mission  operations 

e  Mission  functions 

•  Form  of  management  of  operations 

•  Functions  to  be  centralized  or  distributed 

•  Modularity  of  shelterlzed  configurations 

•  Interconnectivety  among  modules 

•  Oegree  of  resource  clustering  Into  cells 

•  Survivability  and  Interoperability  aspects 

•  Application  of  conventional  and  distributed  processing 

In  addition  to  the  three  cited  references,  a  fourth  source  [25]  was 
utilized  as  an  Indication  of  1990's  and  beyond  considerations  for  Inter-service 
Interoperability.  This  reference  was  examined  for  the  following  characterizations: 

•  Tactical  warfare  environment  of  the  1990's 

t  Principal  requirements  for  command  and  control  systems 
Interoperability 

•  Principal  architectural  considerations 

•  Proposed  architecture  for  Intersystem  Interoperability 

4.3  Distributed  Information  Processing 

This  part  of  the  study  reviewed  material  on  both  requirements  for  and 
architectural  criteria  essential  to  achieving  a  Fully  Distributed  Processing 
System  (FDPS)  capability  [23,  24  and  26],  Enslow's  criteria  for  an  FOPS  was  used 
as  the  basic  criteria  considered  necessary  to  be  present  In  a  system  architecture 
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and  found  that  this  was  fully  consistent  with  characterizations  given  in 
references  [22,  23,  24].  In  particular,  the  following  characteristics  wero 
examined: 

•  Services  to  be  provided  to  users 

•  Subsystems  necessary 

•  Functions  to  be  performed 

•  Architectural  structure  and  major  Interface  and  communications  paths 

•  Aspects  of  managing  system  resources 

•  Heterogeneity  of  elements  comprising  the  system  (local) 

•  Role  of  constituent  and  global  operating  systems 

•  Implication  of  the  role  of  peer  protocols  In  Interprocess 
communications 

•  Multilevel  security  issues 

4.4  Operating  Systems  (Local  and  Global) 

This  part  of  the  study  reviewed  the  literature  on  several  aspects  of 
operating  systems.  The  two  major  considerations  were  for  constituent  (or  local) 
and  global  (or  distributed)  network  operating  systems.  The  references  studied 
were  [5,  14,  15,  16,  19.  23,  24,  26,  27,  28,  29,  30,  31].  The  following 
characterizations  were  sought  In  reviewing  this  literature: 

•  Services  provided  to  the  user 

•  Subsystems  required 

•  Functions  to  be  performed 

•  Architectural  structuring  of  elements 

a  Object-based  system  model 

•  Relationships  between  local  and  global  system  resources 

•  User  Interfacing 

•  Common  command  language 

•  Resource  management  across  a  distributed  environment 

•  Virtual  networking  utility  protocols  for  accessing  remote  resources 

•  Protocols  for  Interprocess  communications 

•  Use  of  local  and  wide  area  networks 

•  Use  of  bridges  and  gateways 

•  Multilevel  security 

Out  of  these  studies  came  a  realization  that  there  were  two  forms  of 
global  operating  systems:  a  network  operating  system  (NOS)  and  a  distributed 
operating  system  (DOS).  While  reference  [28]  represented  the  NOS  form  by  the 
implementation  of  the  National  Software  Works  project,  the  references  for  the 
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Cronus  OOS  [29,  30,  31],  while  called  a  DOS,  realty  exhibited  the  characteristics 
of  an  NOS.  This  therefore  suggested  the  need  to  structure  a  generic  form  of  NOS 
(called  the  GNOS  In  the  study)  to  provide  a  global  view  of  the  type  of  operating 
system  needed  for  command  and  control  protocol  requl rerents  definition.  The  GNOS 
was  constructed  out  of  the  composite  data  given  In  the  references  cited  above. 

4.5  High  level  Protocols  Required  for  GUOS 

A  set  of  virtual  (canonical)  networking  utility  type  of  application 
layer  protocols  were  Identified  out  of  the  GUOS  study  as  being  required.  These 
were  seen  as  constituting  the  elements  of  the  GNOS  Object  (or  Resource)  Manager 
entitles  that  were  needed  for  accessing  resources  or  objects  remote  or  not 
available  on  a  GNOS  node's  constituent  operating  system.  Examples  are  jobs, 
files,  terminals,  devices,  messages,  documents  and  general  processing  resources. 

The  main  references  studied  to  determine  the  characterization  of  the 
virtual  Networking  Utility  Protocols  were  [5,  14,  15,  16,  17,  18,  19,  23,  34,  26, 
27,  28,  31].  The  following  were  examined  to  determine  requirements  for  the  GNOS 
Networking  Utilities: 

•  Services  to  be  provided  to  the  GNOS  resource  managers 

•  Functions  needed  to  be  performed 

•  Peer  protocols  needed  to  provide  the  utilities 

•  Support  protocols  for  syntax  (presentation  service),  conversational 
mode  control  (session)  and  Interprocess  communications  (transport 
connections  or  connectionless  services) 

4.G  Networking  Architecture  and  Protocol  Suites  (ARPANET/DOD  and  ISO/OSI) 

Two  major  networking  architecture  and  protocol  suites  were  studied:  the 
ARPANET/DOD's  [1,  10,  11,  32-40]  and  the  ISO's  OSI/RM  [5,  14,  18].  Similarities 
in  the  two  architectures  were  examined  In  addition  to  the  services  offered  to 
users,  functions  performed  and  elements  of  the  peer  protocols.  In  the  case  of 
services  needed  In  the  local  area  network  partition  of  the  architecture  model,  the 
protocol  developments  under  way  by  the  IEEE's  Project  802  for  LAN's  were 
considered  [21,  41],  in  addition,  liaison  was  maintained  with  experts  working  on 
these  standards  bodies  to  track  progress  developing  protocols.  On  the  Issue  of 
whether  to  maintain  the  formal  layering  of  protocols  as  exhibited  In  the  OSI/RM, 
references  [1,  5,  14,  19,  20,  40,  42,  43,  44]  were  studied  and  formed  a  basis  for 
understanding. 

4.7  Performance  Characteristics  of  Local  Area  Networks 

Local  Area  Networks  (LAN's),  employing  various  media,  topologies, 
medium  access  methods  and  two  major  logical  link  user  service  protocols,  exhibit 
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different  characteristics  In  services  offered  versus  performance,  under  varying 
loading  conditions.  The  literature  was  studied  In  order  to  characterize  what 
already  had  been  analyzed  and  reported  by  others.  The  main  aspect  of  LAN's  deemed 
to  constitute  the  mainstream  In  this  regard  was  the  work  of  the  IEEE's  Project  802 
LAN.  This  work  analyzed  the  CSMA/CD,  Token  3us  and  Token  Ring  medium  access 
methods  by  an  Impartial  working  group  of  experts.  References  studied  were  [1,  30, 
41,  43,  45-57].  The  following  characteristics  were  studied: 

a  Connection-oriented  and  connectionless  services 

•  Singlecast,  multicast  and  broadcast  features 

•  Medium  access  method 

a  Throughput  versus  offered  load 
a  Delay  versus  throughput 
a  Overhead  contributed  from  protocol  layers 
4.8  Simulation  and  Modeling  Perfcrmance  Evaluation  of  TCP/ICP/LAN  Protocols 

This  portion  of  the  study  constructed  a  discrete-event  simulation  model 
of  a  suite  of  LAN-based  protocols  and  conducted  performance  evaluations.  The 
primary  reference  sources  used  for  the  model's  architecture  was  C35,  36,  58,  59]. 
The  model's  design  was  constructed  to  be  very  general-purpose  with  facilities 
incorporated  to  enable  varying  a  number  of  parameters. 

The  objectives  set  out  for  the  modeling  are  given  in  Table  4.8.  In 
summary,  the  objective  was  to  model  and  evaluate  LAN  and  internet  configurations 
of  TCP  and  IP  protocols  operating  with  either  Ethernet,  IEEE  802's  CSMA/CD,  IEEE 
602 's  Token  8us  or  IEEE  802 's  Token  Ring,  for  the  LAN  cases,  and  simulated  effects 
for  Wide  Area  Network  cases.  Later,  If  resources  permitted,  an  additional  set  of 
objectives  was  to  simulate  several  of  the  ARPANET/DOD  higher  layer  protocols  for 
evaluation,  too. 

In  particular,  throughput  and  delay  performance  under  a  variety  of  user 
and  configuration  conditions  were  the  primary  parameters  to  be  measured.  A 
special  property,  highlighted  In  reference  [08],  was  the  capability  to  represent 
different  configurations  of  local  resources  (i.e,  processor  speed,  etc.)  and 
ascertain  the  sensitivity  effects  when  variations  were  made. 

Implementation  of  the  simulation  design  was  made  on  a  Harris  H-800 

machine. 

The  programs  were  written  In  5LAM/F0RTRAN  and  documented  In  a 
Progressive  Project  Document  (PPD). 
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Table  4.8.  Objectives  for  Simulation/Modeling 


A.  GENERAL 

1.  Represent  operations  of  000/IEEE  302  hierarchy  of  layered  protocols  In 
multiple  nodes  attached  to  a  single  LAN  and  with  an  Internet  of 
multiple  LAN's  connected  (e.g.,  employing  DON,  X.25  MAN  protocol 
effects). 

Z.  Derive  quantitative  data  on  the  external  (as  seen  on  the  media  cable) 
as  well  os  Internal  (as  seen  inside  a  node  at  special  Interest  points) 
operational  performance  of  primary  functions  and  events  (In  terms  of 
timing  and  resource  utilization). 

3.  Represent  selected  baseline  versions  of  the  protocols  and  then  vary 
protocols  to  determine  effects  within  the  LAN  environment  (e.g., 
subsetting  to  Improve  measures  of  performance  or  Improve  a  resource 
utilization). 

4.  Obtain  a  quantitative  understanding  and  a  data  base  of  what  Is 
happening  so  as  to  determine  cost/benefit  trades,  which  can  lead  to 
recommendations  to  customer. 

5.  Primary  protocols  of  Interest  to  model  are? 

-  LAN  -  Ethernet  Blue  Book  CSMA/CD  Layers  1  and  2 

-  IEEE  802.3  CSMA/CO  Layers  1  and  * 

IEEE  802.4  Token  Bus  Layers  1  and  * 

-  IEEE  802.5  Token  Ring  Layers  1  and  * 

-  *IEEE  802.2  Logical  Link  Control  Type  1  Datagram,  and  then 

Type  2  Connection  Service 

-  TRANSPORT  -  Transmission  Control  and  Internet  Protocols  of 

000  TCP/IP 

-  H'iGHER  LAYERS  -  TELNET,  File  Transfer  and  Electronic  Mall 

OOD  Protocols  as  a  minimum 

-  WAN  -  00N,  ARPANET,  X.25  Effects 

6.  Variables  of  Interest: 

Topology  and  Media  Access  Protocols  (CSMA/CD,  Token  Bus,  Token  Ring) 
Cata  Rates  (1,  10,  50  Mb/s) 

Cable  Length  i0.5,  1  and  2.5  M) 

-  Number  of  Nodes  (2,  10,  50,  100,  200,  500) 

Types  of  Nodes  (Terminal  Concentrator,  Resource  Server,  General 
Purpose  Work  Station,  Computer  Host,  Gateway) 
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Table  4.8.  Objectives  for  Simulation/Modeling  (Continued) 


Loadings: 

User  Interface  Ports  (1,  5,  10,  50) 

User  Traffic  (quantity,  size,  frequency,  concurrency,  TBD) 
Physical  Partitioning  Into  Several  Configurations  (Inboard  versus 
outboard);  1-N  processors,  Interface  buses 
Internal  Resources  Variable  and  Measurable: 

Memory,  buffers,  processor  cycles,  etc. 

7.  Quantitative  Objectives  From  Results 

-  Media  (LAN)  Resource  Utilization  of  Capacity  (e.g.,  throughput, 
delay) 

-  Protocol  Overhead  Effects 

Internal  Processor  -  Memory  Resource  Utilization 
End-to-end  Per  ormance  Effects  at  Interfaces  to: 

Layers  0,  2,  4,  7 


4.9  Generic  Gateways  for  Interoperability 

This  part  of  the  study  reviewed  Mterature  which  dealt  with 
architecture  and  mechanisms  which  permitted  the  Interconnection  of  homogeneous  and 
heterogeneous  network  elements  together.  The  principal  references  utilized  were 
[1  ,  3,  4,  5,  10,  14,  20,  21  ,  36,  41  ,  59-70]. 

The  study  examined  the  principles  of  Internetworking  given  In  [62]  and 
[60]  which  applied  them  to  develop  a  set  of  generic  gateways.  These  generic 
gateways  span  the  full  set  of  OSI/RM  and  DOO/RM  architecture  models,  from  the 
medium  to  the  applications  layer.  Not  only  were  methods  for  Interconnecting  LAN 
to  LAN  by  use  of  bridges  and  gateways  in  [60,  62]  considered,  but  the  larger  scope 
of  LAN  to  WAN  and  ultimately  the  Interconnect^..  of  computer  system  of  vendor  A 
with  computer  system  of  vendor  B  were  considered. 

4.10  Reporting  of  Interim  Study  Results 

The  results  of  the  ongoing  LAN  study  were  reported  on  briefly  each 
month  In  the  RAD  Status  Report  CDRL.  On  a  larger  scale,  two  key  documents  were 
produced.  The  first  [71]  presented  an  Interim  technical  report  covering  the 
period  of  the  first  8  months.  The  second  [72]  was  prepared  and  presented  at  the 
1584  Distributed  Systems  Technology  Exchange  meeting  held  at  RADC.  This 
constituted  a  preliminary  version  of  the  LAN  Interoperability  Study  Report. 
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5.0  STUDY  RESULTS 

This  section  presents  the  detailed  results  of  the  studies  and 
Investigations  conducted.  The  material  presented  herein  Is  organized  for  the  most 
part  In  the  same  order  of  presentation  as  that  In  Section  4.0,  Study  Approach. 

5.1  Department  of  Defense  Study  Findings 

5.1.1  Strategic  Distributed  and  Survlvable  Command  and  Control 

Mn  military  confrontations,  the  United  States  forces  will  face  a 
highly  dynamic  environment.  This  environment  results  from  two  factors:  (1)  the 
Increased  kill -power  and  accuracy  of  modem  weapon  systems,  and  (2)  the  response 
to  this  threat  -  the  high  mobility  of  f-rces  during  battle.  This  environment 
greatly  complicates  effective  command,  control,  and  communications  (C3)  of  U.S. 
forces.  Furthermore,  the  Integration  of  computer  systems  and  the  attendant  need 
for  real-time  information  (data)  transfer  In  a  crisis  compounds  the  problems  of 
developing  a  military  structure  capaole  of  surviving  and  functioning  In  a  nuclear 
engagement"  [73]. 

The  Strategic  Air  Command  (SAC)  has,  as  one  of  Its  missions,  to 
reconstitute  surviving  strategic  forces  for  trans-  and  post-attack  command  and 
control.  To  support  this,  the  DOD  Is  developing  new  technology  for  use  In 

3 

survlvable  C  for  the  strategic  forces.  This  Is  Intended  for  systems  that  can 

support  an  Immediate  U.S.  response  to  an  Initial  attack  as  well  as  meeting  a 

2 

longer-term  requirement  for  C  of  surviving  forces  In  response  to  a  protracted 
nuclear  war.  Therefore,  C^  must  survive  and  offer  sufficient  flexibility  to 
Identify,  reconstitute,  and  employ  surviving  assets  [73,  74]. 

Through  the  current  deployment  of  the  alrbcrne  command  post  (ABNCP)  and 
the  future  ground-based,  mobile  command  center,  called  the  Headquarters  Emergency 
Relocation  Team  (HERT),  the  Strategic  Air  Command  is  attempting  to  develop 
survlvable  C  facilities.  As  a  result,  DARPA,  SAC,  RADC  and  the  Defense 
Communications  Agency  (DCA)  have  agreed  and  are  establishing  a  test  bed  to  conduct 

3 

experiments  and  focus  on  C  support  to  the  ABNCP  and  the  HERT.  The  technologies 

2 

being  developed  and  evaluated  for  use  in  new  distributed  C  strategic  systems 
are  packet-switching,  end-to-end  network  security  and  distributed  knowledge  and 
data  bases. 

In  a  prehostillty  environment,  the  present  SAC  C  system  relies  on 
ground-based  strategic  data  bases.  Information  is  transferred  to  these  data  bases 
by  conventional  communication  systems  such  as  UHF  radio,  commercial  common-carrier 
systems,  and  military  telephone  and  land-line  data  transmission  systems. 
Furthermore,  SAC's  command  and  control  of  its  assets  are  also  supported  via  this 
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collec*  m  of  convnunlcatlon  hardware.  During  trans-  and  post-attack  environments, 
reference  [73]  states  that  "under  such  conditions  many  of  these  systems  will  be  at 
best  fragmented;  l.e.,  partitioned  In  such  a  way  that  Islands  of  communications 
and  data  base  resources  exist.  In  addition,  we  envision  that  groups  of  people 
will  require  access  to  these  data  bases  to  carry  out  their  mission  effectively." 
This  is  Illustrated  by  F1gu**e  5.1.1. 


00*  a  OEFEKE  DATA  NETWORK 

Wt*  a  WWNCCS  INFORMATION  NETWORK.  ETC. 

6  a  GATEWAY 

13457-1 


Figure  5.1.1.  Partitioned  Islands  of  Surviving  C3  Resources 
A  capability  Is  needed,  which  does  not  today  exist,  that  permits  the 
reconstitution  of  the  resources  available  to  these  surviving  Islands,  Into  a 
unified  C3  system.  The  HERT  Is  the  first  step  toward  achieving  this  goal  of 
providing  enduring  C*. 

A  systems  concept  under  evaluation  for  demonstrating  such  a  capability 
Is  the  following  [73]:  "First,  there  Is  a  backbone  communication  system  that  can 
transfer  high-speed,  nearly  error-free  data.  This  system  (packet  radio)  would  be 
deployed  on  SAC  aircraft,  to  the  HERT,  and  at  many  strategic  locations  on  the 
ground.  These  radios  will  be  networked,  providing  a  means  of  rapid  transfer  of 
Information  between  ground-based  and  airborne  strategic  data  bases.  For 
survivability,  all  data  bases  will  be  redundantly  distributed  and  will  be 
supported  by  special-purpose,  distributed  data  base  software  that  ensures  that 
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they  contain  updated,  reliable  Information.  Furthermore,  the  radio*  will  contain 
software  permitting  them  to  dynamically  reestablish  communication  between  airborne 
users  and  to  reestablish  communication  with  surviving  “Islands"  that  would  have 
valuable  strategic  resources.  An  automated  network  management  Includes  the 
reconstitution  of  any  communication  assets  that  survive  the  attack  (e.g. , 
satellites  and  ground-based  systems  that  have  been  augmented  to  operate  In  a 
packet-switched  environment*  [73]). 

5. 1.1.1  Command  and  Control  Architecture 

“As  with  the  telecommunications  and  protocol  architectures  a  slnple 
layering  of  C2  functionality  can  be  envisioned,  as  shown  In  Figure  5. 1.1.1. 

Using  the  Army  as  an  example,  we  have  many  dissimilar  processors  deployed  In  a 
tactical  environment.  Based  on  a  layered  telecommunications  architecture,  we 
assume  that  these  resources  will  be  able  to  communicate  reliably  (using  high  level 
protocols  and  packet  switching)  over  the  backbone  telecommunications  system.  The 
communications,  then,  are  the  nucleus  of  the  C  architecture,  as  depicted  In  the 
figure.  The  next  layer  of  this  architecture  Is  made  up  of  the  C2  processing 
resources  that  are  distributed  throughout  the  battlefield.  These  processors 
support  not  only  specific  user  applications,  but  also  the  higher-level 
telecommunications  protocols  described  above. 
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In  the  battlefield*  we  have  a  collection  of  users  who  need  access  to 
these  processing  resources.  Although  these  users  sight  have  primary  processors 
for  their  use,  the  C  system  architecture  should  be  designed  to  support  an 
environment  whereby  backup  resources  are  automatically  assigned.  Furthermore, 
user  Information  must  be  redundantly  maintained  (for  survivability)  as,  for 
example.  In  a  "backup  cell's"  processor.  Decisions  on  where  the  resources  are 
available  to  support  these  functions  and  on  their  assignment  must  necessarily  be 
accomplished  automatically  If  they  are  to  be  timely  and  efficient.  To  accomplish 
this  management a  distributed  Internetwork  operating  system  must  be  developed. 

Upon  this  distributed  processing  and  telecommunications  foundation 
would  then  be  built  a  collection  of  generic  C2  software  utilities  -  which  may 
also  be  distributed.  Examples  of  such  utilities  are  distributed  data  base 
management  systems,  electronic  mall  systems,  graphics  systems  and  distributed 
teleconferencing  systems. 

Finally,  at  the  outermost  layer,  software  systems  would  be  built  to 
support  specific  C‘  functions.  For  example,  systems  to  automate  force  status 
reporting  and  status  display  are  envisioned,  as  well  as  systems  to  support 
automated  sensor  correlation  and  logistics  planning  [74]." 

5.1.2  Interoperability  of  1990's  Tactical  Command  and  Control  Systems 

A  Joint  Service/Office  of  the  Secretary  of  Defense/ Industry  Working 
Group  examined.  In  1981,  the  Issues  Involved  with  tactical  Information  exchange 
[75]  for  the  1990's  and  concluded  that  tactical  command  and  control  systems  will 
need  to  be  Interoperable  across  the  military  services  and  their  many  operational 
and  support  systems.  This  was  conducted  under  the  auspices  of  the  Command, 

Control  and  Communications  Committee  of  the  National  Security  Industrial 
Association  and  was  funded  by  DARPA  In  conjunction  with  the  Army,  Navy  and  Air 
Force. 

The  study  considered  Intra-  ard  Inter-service  requirements  of  the 
services  for  the  year  2000,  plus  NATO  tactical  operations.  Figure  5.1. 2-1 
illustrates  ore  example  of  an  automated  battlefield  set  of  systems  planned  for  the 
1 990 ' s  needing  to  Interoperate.  The  tactical  warfare  environment  for  the  1990's 
was  considered  to  comprise  dispersed  forces  with  critical  nodes,  having  to  operate 
In  all  weather,  day  and  night.  Non-ilne-of-sight  target  acquisition  would  be 
needed  and  Indirect  weapons  delivery.  Precise  location  and  status  Information 
would  be  needed.  The  enemy  would  be  expected  to  employ  communications  jamming, 
exploitation  and  physical  attack. 
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Figure  5. 1.2-1.  Automated  Battlefield  System  Planned  for  the  1990's 


The  study  established  the  following  as  being  the  principal  requirements: 
Robust/survlvable  and  secure  Information  exchange  capabilities 

-  Support  both  voice  and  data 

Interconnect  hundreds  of  computers  and  thousands  of  users 

-  Provide  high  data  transmission  rates  and  low  bit-error  rates  for 
bursty  traffic  loads 

Provide  for  Interoperability  across  service  and  national  boundaries 
Principal  architecture  considerations  were  formulated.  They  consisted 
of  the  following: 

Increased  Internetting  of  individual  systems  to  be  a  primary  way  to 
achieve  survivability  of  conmunl cations 

-  Internetting  Is  accomplishable  more  efficiently  and  effectively  on 
a  digital  as  opposed  to  an  analog  basis 

-  Bursty  data  traffic  must  be  accommodated  efficiently 
Currently  fielded  communications  equipment  as  well  as  that  now  In 
advanced  engineering  development  or  production  must  be  usable  as 
link  and  network  building  blocks 
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Characteristics  of  the  proposed  architecture  for  a  tactical  Information 
exchange  system  were  as  follows: 

Packet-switched  data  backbone 

-  Standard,  multilayered  conrainl cations  protocols  for  "open  systems 
Interconnection" 

-  Capable  of  being  overlaid  on  existing  link  and  networks 

Figure  5.1. 2-2  Illustrates  the  proposed  cocmon  user's  architecture  for 
a  tactical  Information  exchange  system.  The  system  would  Interconnect  a 
collection  of  communication  networks  for  Inter-servlco  operability  that  have 
Implemented  the  layered  protocol  model.  Figure  5.1. 2-3  Is  an  Illustration  of  the 
DOD's  layered  protocol  architecture  model  referred  to  by  the  study  group. 
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Figure  5. 1.2-2.  Proposed  Common  User  Architecture  for  Tactical 
Information  Exchange  System 
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Figure  5. 1.2-3.  D00  Internet  Protocol  Hierarchy 
As  a  result  of  the  group's  study,  It  made  the  following  recommendations: 


1.  "Adopt  as  a  long-term  policy  the  evolution  of  a  common-user 
tactical  Information  exchange  structure  based  on  an  Integrated 
network  of  existing,  planned  and  conceptual  communications 
systems.  For  digital  data  transfer,  the  structure  should  be  based 
on  packet-switched  networks  with  specifically  defined 
Interconnection  protocols. 

2.  On  a  high  priority  near-term  basl*  complete  the  definition  of  a 
communications  protocol  reference  model  that  supports  DOD  needs 
Including  those  for  security,  precedence.  Inter-network  data 
transfer,  and  support  of  highly  mobile  users. 

3.  When  a  layered  reference  model  has  been  established  for  DOD, 
protocols  should  be  developed  and  standardized  for  each  layer  of 
the  reference  model  to  support  information  transfer. 
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4.  Transition  plans  for  steps  toward  a  common-user  tactical 
Information  exchange  system  should  be  developed  and  Implemented 
both  at  the  Individual  service  level  and  at  the  joint  service 
level.  The  development  of  a  packet-switched  data  network  using 
multichannel  communications  equipment  for  the  basic  physical  link 
Is  an  example. 

5.  Special  emphasis  must  be  given  to  the  development  of  network 
management  and  control  concepts  and  protocols  as  they  apply  to  the 
recoranended  cannon-user  system,  particularly  with  respect  to 
precedence,  security  and  auditing  features. 

6.  A  unified  or  coordinated  test  program  should  be  established  to 
support  the  development  and  testing  of  000  Information  exchange 
standards  and  protocols. 

7.  Accelerate  conceptual  and  system  design  efforts  relative  to  the 
organization,  management,  control  and  accessibility  of  tactical 
Information  (at  the  application  and  utility /presentation  layers  of 
the  Interconnection  model). 

8.  Current  plans  for  the  fielding  of  tactical  communications  equipment 
should  be  reviewed,  with  respect  to  how  well  they  support  the 
recommended  future  tie  architecture  framework,  this  Is  not  a 
recommendation  to  stop  fielding  currently  planned  communications 
Improvements  until  the  tie  framework  architecture  Is  Implemented. 

9.  Renewed/Increased  effort  should  be  addressed  to  the  following: 
e  The  use  of  anti  jammer  weapons  to  off-load  communications 

antijam  margin  requirements,  particularly  against  airborne 
jammers 

a  The  development  of  deployable  coomunl  cations  relay 

capabilities,  particularly  airborne 

a  The  development  of  multifunction  RF  systems  supporting 

communications,  navigation,  Identification  and  surveillance" 

5.1.3  Tactical  Command  Control  and  Communications  for  the  U.S.  Army 

'  o 

"The  overall  trend  toward  Increasing  use  of  digital  data  for  C4,  and 
new  Atmy  concepts  In  survlvable  command  structures  Implies  numerous  problems  for 
developing  future  Army  Command,  Control,  and  Communications  (C^)  systems.  For 
example,  the  Army's  Combined  Arms  Combat  Development  Activity  (CACDA)  developed  a 
concept,  called  the  Cellular  Command  Post  (CCP),  that  attempts  to  ensure  the 
survivability  of  a  command  center  In  a  tactical  nuclear  environment  through 
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distribution  and  replications  of  the  functional  areas  presently  consolidated  Into 
one  Tactical  Operation  Center  (TOC).  In  the  concept,  Division  TK's  are  divided 
Into  14-16  cells  of  about  20  persons  each.  These  cells  are  replicated  at  least 

twice,  and  for  survivability  they  are  situated  more  than  5  km  apart. 

2 

This  TOC  architecture  raises  problems  of  distributing  C  Information 
and  retaining  concurrent  replicated  data  bases  at  the  cells.  If  assumption  of 
responsibility  Is  to  be  possible  at  "backup"  cells,  then  their  Infurmatlon  must  be 
as  current  as  that  used  by  any  (all)  other  cells.  The  Division  CCP,  however,  has 
only  a  microscopic  view  of  the  battlefield.  The  need  for  real-time  information 
distribution  and  maintenance  of  concurrent  data  bases  In  a  widely  mobile,  dynamic, 
highly  dispersed  battlefield  Is  a  very  complex  problem. 

As  a  second  example,  the  Army's  Training  and  Readiness  Command  (TRADOC) 
has  been  developing  an  Army  21  concept.  In  this  concept,  the  Army  of  the  future 
Is  envisioned  as:  1)  being  able  to  see  deep  behind  enemy  lines;  2)  being  highly 
mobile  and  maneuverable;  and  3)  being  able  to  strike  behind  the  forward  line  of 
enemy  troops.  As  part  of  this  concept.  It  Is  anticipated  that  tnese  highly  mobile 
and  maneuverable  fighting  units  will,  at  times,  be  "communications  Isolated"  from 
other  mobile  units  or  even  from  higher  echelons  of  command.  Under  such 
conditions,  commanders  will  presumably  proceed  on  their  own  until  communications 
are  reestablished. 

It  Is  clear  from  this  description  that  In  the  Army  21,  conmunl cations 
systems  that  can  automatically  reconstitute  themselves  would  meet  an  Important 
need  and  be  of  significant  advantage.  Similarly,  processing  resources  that  could 
function  with  communications  systems  that  may  be  Intermittently  disabled  and 
subsequently  reconstituted  could  provide  significant  Improvements  In  battlefield 
information  transfer.  Specifically,  If  a  mobile,  highly  maneuverable  unit  should 
lose  communications.  It  might  proceed  to  execute  a  mission  and  subsequently 
reappear  In  ?.n  unexpected  location.  In  that  case,  coitsnunl cations  to  that  unit 
might  not  be  reestablished  efficiently.  However,  If  the  communications  systems 
are  designed  to  reconstitute  themselves  dynamically,  then,  If  any  possibility  for 
communications  exists,  the  system  will  automatically  establish  the  appropriate 
data  paths  regardless  of  user  locations.  Similarly,  If  processors  are  designed  to 
support  reliable  end-to-end  telecommunications  protocols  regardless  of 
Interruptions,  then  th  ,  could,  as  paths  are  dynamically  established,  transfer  the 
data  necessary  for  effective  C^. 
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The  p  rob  lea  of  Information  management  In  *  tactical  environment  Is  even 
further  complicated  by  the  fact  that  many  dissimilar  processors  are  used  by 
battlefield  units.  Trying  to  disseminate  Information  reliably  between  the 
different  machines  (which  are  loosely  coupled  through  various  Army 
telecommunications  systems)  becomes  a  classic  problem  In  distributed  systems.  One 
solution  to  this  problem  would  be  to  converge  on  a  specific  machine  architecture 
and  system/appllcatlon  software.  However,  a  more  pragmatic  approach,  given  the 
number  of  computers  already  In  the  Army's  Inventory.  Is  to  develop  a  software  and 
telecommunications  environment  that  supports  data  transfer  between  dissimilar 
processors.  In  this  respect,  Anqy  battlefield  needs  are  not  so  different  from 
commercial  user  needs"  [74]. 

5.1.4  Department  of  Defense  Protocols  Policy 

*». 1.4.1  Use  of  Military  Versus  National /International  Standards 

Local  networks  are  well  suited  to  Intrap'iatfora  (vehicle,  building,...) 
applications.  Long  haul  nets  (e.g.,  ARPANET,  SATNET,  Defense  Data  Net,...)  will 
be  needed  for  wide-area  communications.  Packet  radio  or  other  mobile  digital 
communication  system  will  be  needed  In  tactical  applications  Involving  battlefield 
automation.  No  single  technology  Is  ideal  for  all  applications,  yet  the  full 
collection  of  systems  must  1 nteroperate. 

The  military  communicator  faces  a  basic  dilemma;  should  military  data 
communications  systems  use  special  protocol  standards  unique  to  the  military,  or 
should  they  use  prevailing  national  and  International  standards?  References  [76, 
77,  78]  discuss  the  policy  and  technical  facets  of  this  dllerana. 

On  this  issue,  D00  Instruction  4120.20  entitled  "Development  and  Use  of 
Non-Government  Specifications  and  Standards"  sets  forth  the  prevailing  policy  of 
the  DOD  concerning  adherence  to  national  and  International  specifications  and 
standards.  As  applied  to  protocol  standardization,  DODI  4120.20  requires 
standards  be  adopted  as  DOD  standards  In  lieu  of  the  development  and  promulgation 
of  new  documents.  The  Instruction  does,  however,  allow  exceptions  as  necessary  to 
provide  for  unique  military  requirements.  Clarification  of  the  DOD  policy  by 
Dr.  Richard  OeLauer  (Undersecretary  of  Defense  for  Research  and  Engineering)  was 
set  forth  In  a  memorandum  dated  23  March  1982.  While  reiterating  the  need  to 
utilize  existing  national  and  International  standards  where  possible,  he  also 
reaffirmed  the  current  policy  of  conformance  to  the  existing  DOD  IP  and  TCP 
standards  because  "military  requirements  for  Interoperability,  security, 
reliability  and  survivability  are  sufficiently  pressing  to  have  justified  the 
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development  and  adoption  of  TCP  and  IP  In  the  absence  of  satisfactory 
non- Government  standards." 

The  DOD  Internet  Architecture  Model  [77]  has  evolved  over  a  period  of  7 
or  8  years.  In  concert  with  Increasing  DOD  experience  with  packet-switched 
computer  communications  technology.  The  model  makes  full  use  of  the  TCP/IP  family 
of  DOD  protocols.  The  principal  method  for  achieving  interoperability  in  the  DOD 
Internet  Model  Is  the  use  of  a  standard  Gateway  which  can  route  Internet  traffic 
from  one  net  to  another  and  the  use  of  a  standard  set  of  protocols  operating  above 
the  Internetwork  layer.  Gateways  are  specifically  Intended  to  support  the 
Interconnection  of  heterogeneous  packet  nets.  The  U.S.  DOD  Is  moving  In  the 
direction  of  a  multi-network  or  "internet"  architecture  based  on  the  concept  of 
Internet  datagrams  and  gateway  Interconnection  among  diverse  packet  networks. 

Table  5. 1.4. 1-1  lists  assumptions  and  requirements  which  Influenced  the 
DOD  Internet  Model  while  Figure  5. 1.4.1  illustrates  tho  DOD  Internet  Protocol 
hierarchy.  This  shows  protocols  above  the  TCP/IP.  DOD  has  plans  for  a  number  of 
other  protocol  standards  as  shown  by  Table  5. 1.4. 1-2.  These  will  be  done  mainly 
through  contractual  support  and  coordination  with  the  NBS.  The  DOD  has  developed 
a  working  agreement  for  the  development  of  protocol  standards  with  che  NBS  through 
which  It  will  assist  the  DOD  with  Its  technical  expertise  and  also  provide 
representation  for  the  DOD  In  civilian  standards  forums. 

5. 1 .4.2  Inquiry  Into  Use  of  DOD  Versus  ISO  Protocols 

The  LAN  study  learned  early  of  a  major  Issue  which  developed  within  the 
Government  over  the  continued  use  o*  TCP  and  higher  layer  protocols  for 
networking.  The  DOD  Is  proceeding  with  Implementation  of  the  Defense  Data  Network 
( DDN)  using  the  TCP  protocol  [2].  At  the  same  time,  the  National  Bureau  of 
Standards  has  proposed  adoption  of  a  Federal  Information  Processing  Standard  for 
the  Transport  Protocol  utilizing  the  Transport  layer  specifications  developed  by 
the  ISO.  Both  the  TCP  and  the  FIPS  transport  are  reported  to  incorporate  the  same 
functional  capabilities. 

This  will  become  more  complex  as  the  ISO  Is  developing  s  connectionless 
internet  Protocol  which  also  Is  reported  to  Incorporate  the  same  functional 
capabilities  as  the  DOD's  IP.  Further,  both  DOD  and  ISO  are  developing  suites  of 
higher  layer  protocols  for  use  above  the  Transport  layer. 

At  the  Invitation  of  the  DOD,  the  National  Research  Council  of  the 
National  Academy  of  Science  and  the  National  Academy  of  Engineering  set  up  a 
committee  to  examine  the  layer  4  protocols  and  make  recommendations  regarding 
tholr  use.  This  study  effort  began  during  the  summer  of  1983  and  Is  jointly 
sponsored  by  the  DOD  and  NBS. 
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Table  5.1. 4.1-1.  Assumptions  and  Requirements  Influencing  000  Internet  Model 

1.  Heterogeneous  Packet  Networks  (l.e..  Physical,  Link,  Network  Layers 
differ) 

2.  Datagram  (connectionless)  Service  at  Internet  Layer 

3.  Architectural  Provision  for  Interoperable  Tactical  and  Strategic 
Communication 

4.  High  Reliability  and  Survivability  Under  Hostile  Conditions 

5.  Combined  Voice  and  Data  Services 

6.  Interactive,  Real-Time,  Transaction,  and  Bulk  Data  Transport 
Services 

7.  Precedence  ana  Security  at  Several  Lavers 

8.  Broadcast/Multlcast  Services 

9.  Host-Host  File  Transfers  and  File  Accoss 

10.  Widely  Varying  Terminal  Types  Using  Remote  Service  Hosts 

11.  Electronic  Message  Switching  Service  Utilizing  Different  Transport 
Protocol s 

12.  Multimedia  (Text,  Fax,  Graphics,  Voice)  Electronic  Messaging 

13.  Distributed,  Redundant  Name-to-Address  Translation  Services 

Mr.  Jerome  D.  Rosenberg,  Senior  Staff  Officer  of  the  National  Research 
Council  was  contacted  several  times  early  during  the  LAN  study  to  determine 
progress  of  the  study.  The  LAN  study  also  learned  of,  requested,  and  obtained 
copies  of  correspondence  [79,  84]  between  the  Computer  Business  Equipment 
Manufacturer's  Association  ( CBENA )  and  the  OCD's  Deputy  Undersecretary  of  Defense 
Research  and  Advanced  Technology  over  this  set  of  Issues. 

CBEMA  [79]  expressed  the  following  request: 

"We  request  that  the  Department  of  Defense  refrain  from  Issuing 
requl rements  frr  TCP  pending  a  resolution  of  the  protocols  question  within  the 
Government.  We  also  request  that  every  effort  be  made  to  avoid  duplication  In 
protocols  above  layer  4  which  have  not  yet  been  adopted  as  military  standards." 

The  DOD's  response  letter  [60]  provided  the  following  views  (extracted 
from  DOD's  letter): 
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Figure  5. 1.4.1.  00D  Internet  Protocol  Hierarchy 
Table  5. 1.4. 1-2.  DOD  Protocol  Development  Time  Table 


Protocol 

Message  Protocol  (MP) 

File  Transfer  Protocol  (FTP) 

Terminal  Handling  Protocol  (THP) 
Application  Level  Protocol  (ALP) 
Presentation  Layer  Protocol  (PLP) 

Session  Control  Protocol  (SCP) 

Transmission  Control  Protocol  (TCP) 
Internet  Protocol  (IP) 

Gateway-to-Gateway  Protocol  (GGP) 

Datagram  Network  Interface  Protocol  (DNIP) 

X-Task  Completed 
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“Use  of  a  standard  DOD  transport  layer  protocol  Is  sound: 

1.  DOD  military  requirement... drives  the  need  for  a  standard  host 
computer-to-host  computer  protocol  w;th  transport  protocol 
functionality. 

2.  At  the  present  time,  TCP  Is  In  the  use  in  many  operational 
environments,  but  TP  (NBS  ^IPS  Transport  Protocol)  remains  a  "paper 
protocol"  which  has  been  implemented  only  In  a  laboratory 
environment. 

3.  TP  is  not  a  fully  specified  protocol. 

4.  Use  of  TCP  provides  DOD  system  host-to-host  Interoperability  with  a 
proven  protocol.  There  Is  no  alternative  commercially  supported 
standard  available  today. 

We  have  also  provided  our  requirements  for  protocols  above  the 
transport  layer  to  the  NBS  and  are  working  closely  with  NBS  personnel  so  that  DOD 
requirements  can  be  reflected  in  FIPS  standards  for  those  higher  protocol  levels." 

The  LAN  study  has  maintained  IJalson  with  contacts  within  the  Defense 
Communication  Agency  (OCA)  of  the  DOD  who  are  providing  input  for  DOD  to  the 
National  Research  Council's  study.  This  liaison  will  be  continued  as  the 
Council's  inquiry  progresses. 

At  the  time  of  writing  this  report,  the  findings  and  recommendations 
from  the  Inquiry  had  not  been  finalized  to  allow  public  disslmi nation.  The 
results  are  expected  to  have  a  significant  impact  on  future  DOD  direction,  though. 
5.2  Air  Force  Study  Findings 

5.2.1  Air  Force  Protocols  Policy 

The  Air  Force  established  In  1983  [12,  13]  a  policy  for  packet-oriented 
local  area  networks.  It  states  the  following  as  policy: 

"The  DOD  Standard  Transmission  Control  and  Internet  Protocols  (TCP/IP) 
are  the  Air  Force  standards  for  connection-based  transport  and  Internetwork 
services  within  packet-orien.ed  local  area  networks." 

This  policy  and  other  LAN-related  policies  as  they  are  developed  are  to 
be  incorporated  In  the  USAF  LA  architecture  currently  being  developed.  The  Air 
Force  Internetwork  architecture  is  Intended  to  provide  a  common  base  within  which 
to  provide  Interoperability  among  diverse  data  communities  that  will  exist  In  the 
military  environment.  The  datagram-based  Internet  Protocol  (IP)  Is  to  allow  the 
flexible  evolution  of  a  variety  of  application  level  functions,  while  allowing 
simple  gateways  to  Interconnect  long-haul  and  local  area  networks.  The 
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Transmission  Control  Protocol  (TPC)  Is  to  provide  the  end-to-end  virtual  circuit 
service  allowing  reliable  transmission  to  take  place  between  subscriber  hosts  and 
terminals  In  a  catenet  [10]. 

The  following  have  been  Identified  by  the  Air  Force  [12]  as  pivotal 
technologies: 

1.  Inexpensive,  powerful  microcomputers 

2.  Inexpensive,  high  bandwidth  communications 

3.  Proven  efficiency  of  packet  switching  for  bursty  computer 
communications 

The  key  to  realizing  local  area  network's  potential  Is  with  a  strategic 
approach  [12]: 


1.  Build  software  to  span  generations  of  hardware 

-  Modular  software 

High  level  standard  languages 

-  Hardware  Insensitive 

2.  Plan  to  replace  hardware  by  newer  higher  performance  price  offerings 

-  Modular  hardware 

-  Vendor  Independence  at  logical  Interfaces 

3.  Be  willing  to  pay 

-  System  performance 

-  Software  not  opltlmized  for  speed,  memory  utilization 

-  Initial  cost-buy  more  hardware 

4.  Mount  alternative  attack  on  multilevel  security  based  on 
encryption,  intricately  related  to  protocols 

5.  Simplify  gateways  by  judicious  protocol  management 

Some  choices  are  considered  [12]  first  order  while  others  are 
considered  second  order: 

1.  Protocols  and  their  management  (first  order) 

Layered  architecture  of  vendor  Independent  protocols 

Choice  of  protocols,  especially  at  Internetwork  layer  and  above 

Standardization  and  evolution  of  these  protocols 

2.  Characteristics  of  LAN' s  (second  order) 

Topology  (ring,  bus,  mesh) 

-  Medium  (twisted  pair,  coaxial  cable,  fiber  optics) 

-  Access  mechanism  (contention,  deterministic) 

Modulation  (baseband,  broadband) 
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5.2.2  Air  Force  LAN  Architecture 

The  Air  Force  In  1983  [12,  13]  set  up  working  groups  to  expedite  the 
development  on  an  Interim  basis  the  Initial  development  of  the  USAF  LAM 
architecture  and  road  map.  The  LAN  $tuc(y  contacted  the  A1:  Staff  office  during 
the  summer  of  1983,  obtained  a  draft  copy  of  the  USAF  LAN  Architecture  and 
conducteo  an  analysis,  presented  In  the  following  paragraphs. 

Table  5.2.2  presents  the  current  USAF  definition  for  a  local  area 
network  (LAN). 

Table  5.2.2.  Local  Area  Network  (LAN) 
e  Definition* 

-  A  data  telecommunications  system 

Designed  to  allow  a  number  of  Independent  devices  (e.g.,  host 
computers,  work  stations,  terminals,  peripherals)  to 
communicate  with  each  other 

Generally,  LAN's  are  restricted  to  small  geographical  areas  and 
utilize  fairly  high  data  rates 

-  A  LAN  Is  typically  a  subsystem  of  a  larger  Information 
processing  system 

-  Provides  functions  of  data  transport,  switching  and  network 
management 

Excluded  functions  are  higher-layer  Information  processing 
functions  (e.g.,  file  transfer,  management  Information  systems) 

-  LAN's  have  both  physical  and  logical  elements  (e.g.,  cable, 
media  Interface,  protocol  layers) 


♦Source:  "USAF  Local  Area  Network  (LAN)  Architecture"  (Draft),  20  July 
1983,  HQ  USAF/SITT 

5. 2. 2.1  Purpose 

The  USAF  LAN  Architecture  provides  a  set  of  guidelines,  policies  and 
standards.  It  Is  intended  to  structure  the  design,  selection,  implementation  and 
operation  of  LAN  systems  to  support  user  requirements.  It  addresses  such  aspects 
as: 

Securl ty 

-  Survivability 

-  Endurance 
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-  Supportabll 1 ty 
Sustainability 
Interconnection 
Interoperation 

-  Network  management/control 

It  recognizes  differences  In  user  requirements  and  provides  for  a 
flexible/modular  approach.  The  ultimate  LAN  system  is  considered  beyond  the 
current  state  of  the  art.  The  architecture  must  support  technological  evolution 
and  be  time-phased  to  enable  evolving  to  the  long-term  requirements  anu 
capabilities. 

5. 2. 2. 2  LAN  Assumptions 

The  following  assumptions  were  given: 

1.  Primary  emphasis  is  to  support  minimum-essential  mission 
requirements. 

2.  Support  of  data  and  resource  sharing  at  local,  regional  and  global 
levels  required  of  common-user  data  telecommunications. 

3.  Full  Interconnection  and  Interoperability;  both  within  ard  between 
LAN's,  are  fundamental. 

4.  Evolutionary  approach  from  near  to  long  term. 

5.  Network  access  control,  security  and  audtlng  capabilities  needed. 

6.  General  trend  will  be  toward  distributed  processing  and  distributed 
data  bases. 

7.  Demands  will  require  very  high  speed  (large  throughput)  data 
transmission. 

8.  Value-added  network  services  will  be  needed  (e.g.,  electronic  mall, 
file  servers)  to  evolve. 

9.  Evolutionary  trend  to  add  video,  voice,  facsimile  to  data  handling. 

5.2. 2. 3  Near-Term  and  Long-Term  LAN  Planning  Factors 

A  set  of  near-term  LAN  planning  factors  was  established  as  well  as  a 
set  of  long-term  ones.  These  are  presented  In  Tables  5. 2. 2. 3-1  and  5. 2. 2. 3-2. 

5. 2. 2. 4  Other  Aspects  of  Architecture 

At  the  time  the  draft  USAF  Local  Area  Network  (LAN)  Architecture 
document  was  Issued  (20  July  1983),  several  appendix  sections  were  Incomplete  and 
were  to  be  provlaed.  They  comprised  the  following: 
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Table  5. 2. 2. 3-1.  USAF  Hear-Term  LAN  Planning  Factors* 

a  Conroerclal  technology  Mill  determine  LAN  capabilities  Initially 

e  Whether  comnerclal  Industry  Incorporates  military  needs  Is  a 
marketplace  Issue 

e  LAN  must  support  transmission  of  digital  data  and  support  of 
wideband  services  preferred 

e  LAN  must  support  full  Interconnection  and  Interoperability  of  an 
LAN  connected  device 

e  LAN's  must  employ  D00  TCP  (Full)  for  transport  services  and  IP  for 
Internet  services 

e  LAN's  must  Interconnect  with  other  LAN's  and  wide  area  networks 
(e.g.,  DON)  using  multiple  routes  and  diverse  transmission  media 
for  survivability  endurance 

e  LAN's  must  support  Incremental  capacity  expansion 

e  LAN's  must  avoid  single-point  failures  through  distributed  designs 
with  functional  replication 

e  LAN's  should  provide  preferential  speed-of-servlce  and  delivery 

e  Network  access  control  to  evolve  to  secure  LAN  Implementations 

e  LAN  network  Interface  units  (NIU's)  should  Implement  protocols 
through  transport  layer 

•  All  Internet  Protocol  (IP)  features  and  services  to  be  supported 

e  NIU's  should  be  software  executable  from  downline-loadable  RAM 
storage  to  support  network  management  evolution 

•  LAN  component  elements  should  support  functional  expansion  and 
growth 

♦Source:  HQ  USAF/SITT  DRAFT 
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Table  5. 2. 2. 3-2.  USAF  Long-Term  LAN  Planning  Factors* 

•  LAN's  must  support  full  range  of  transmission  requirements  (e.g., 
data,  voice,  facsimile,  video,  alarms  and  sensors) 

•  LAN’s  must  support  full  Interconnection  and  Interoperability 
between  Integrated/hybrid  Information  system  components 

•  Dependent  upon  a  universal  application  of  a  vendor-independent 
protocol  architecture 

•  Oynamlc  networking  Interconnections  and  configurations  required  to 
withstand  stresses 

•  Full  services  required  to  higher-level  protocol  users  of  LAN's 

•  LAN's  to  support  Incremental  growth  In  capacity,  with  fiber-optic 
systems  preferred 

•  LAN's  to  support  applications  (e.g.,  interactive  processing,  file 
transfers,  electronic  data/voice  mall,  data/volce/vldeo 
teleconferencing,  workload  sharing,  distributed  processing/data 
bases,  connections,  multicart  and  broadcast) 

•  Avoid  single-point  failures 

•  Provide  adaptive  resource  allocation 

•  Network  access  control  to  support  multilevel,  controlled  and  system 
high  inodes  of  operation 

•  Network  Interface  units  perform  as  full  network  front  ends  through 
virtual  terminal  service  protocols 

t  Component  elements  should  support  expansion 


♦Source:  HQ  USAF/SITT  DRAFT 
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1.  LAM  Protocol  Architecture 

2.  LAN  Operation  and  Maintenance  Concepts 

3.  LAM  Network  Management  and  Control 

4.  LAM  Security  Architecture 

Completed  versions  of  these  were  not  received  by  the  LAN  study  In  time  to  take 
them  Into  account. 

5.2.3  Air  Force  Local  Area  Network  Systems  Program  Office  (AFLAN  SPO) 

A  joint  Air  Force  Cociounl  cations  Command  (AFCC)  and  Air  Force  Systems 
Comn&nd  (AFSC)  systems  program  office  was  set  up  In  1983  to  deal  with  setting 
architecture  direction  for  Air  Force  use  of  LAN's.  At  the  time  of  writing  this 
report  the  AFLAN  SPO  had  not  Issued  Its  rr commendations  on  LAN  architecture  or 
protocols.  This  will  set  a  very  Important  direction  when  Issued  though. 

5*3  Industry  Study  Findings 

While  the  Intended  use  of  LAN  protocols  out  of  this  study  Is  for 
command  and  control  systems  within  the  military  context,  the  Impact  of  DGDI 
4120.20,  discussed  In  Paragraph  S. 1.4.1  herein,  places  the  consideration  of 
Industry  protocol  standards  Into  relevance.  The  study,  therefore.  In  addition  to 
examining  strategic  and  tactical  requirements  and  architecture  for  C2  also 
looked  at  what  Industry  was  doing  and  where  It  was  going. 

5*3.1  Open  Systems  Interconnection 

The  primary  Indicator  for  Industry  direction  considered  was  the  work 
under  way  within  the  context  of  the  Open  Systems  Interconnection  Reference  Model 
( OSI/RM)  being  developed  within  organizations  such  as  ISO,  CCITT,  ECMA,  ANSI,  N8S 
and  IEEE.  In  addition,  IBM's  System  Network  Architecture  (SNA)  was  considered. 

The  scope  of  the  OSI/RM  work  Is  worldwide.  It  Is  now  an  International 
agreement  between  ISO  and  CCITT  for  all  future  development  of  standards  for 
worldwide  distributed  Information  systems  [14],  OSI  has  been  designed  to  deal 
with  the  heterogeneous  environment  of  diverse  designs  and  manufacture.  On  the 
other  hand,  network  architecture  developed  by  Individual  companies,  like  IBM's 
Systems  Network  Architecture  (SNA)  [20,  82]  was  designed  for  a  homogeneous 
environment,  where  all  components  are  designed  and  controlled  by  one  organization. 

In  the  command  and  control  environment,  exemplified  by  Paragraphs  5.1.1 
and  5.1.2  above,  those  environments  exhibit  heterogeneous  rather  than  homogeneous 
characteristics,  and  thus,  the  approach  embodied  within  the  OSI/RM  seems  to  be 
highly  relevant.  Therefore,  DODI  4120.20  and  the  heterogeneity  property  of  the 
OSI/RM  strongly  suggests  Its  consideration  to  the  command  and  control  set  of 
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Issues.  On  the  other  hand,  the  OSI/RM  has  not  taken  Into  account  the  additional 
special  requirements  which  a  survlvable  and  secure  [81]  military  system  must  deal 
with.  It  would  be  expected,  thei,,  that  the  OSI/RM  would  lack  some  functionality 
needed  by  C2  in  those  -espects.  OSI  committees  have  recognised  the  need  for  and 
plan  to  Incorporate  security  services  and  functions  Into  the  OSI/RM. 

The  OSI/RM  shown  In  Figure  5. 3. 1-1,  Is  an  abstract  description  of 
Interprocess  communication.  OSI  is  concerned  with  standards  for  communication 
between  end  systems.  In  the  OSI/RM,  communication  takes  place  between  application 
processes  running  In  distinct  systems.  An  end  system  Is  considered  to  be  one  or 
more  autonomous  computers  and  their  associated  software,  peripherals,  and  users, 
that  are  capable  of  Information  processing  and/or  transfer.  Although  OSI 
technologies  could  be  used  within  a  system  (and  It  would  be  desirable  for  Intra- 
and  Inter-system  communication  to  appear  as  similar  as  possible  to  the  user).  It 
Is  not  the  Intent  of  OSI  to  standardize  the  Internal  operation  of  each  Individual 
system  [14]. 


OSI  Is  concerned  not  only  with  the  transfer  of  Information  between 
systems,  l.e. ,  transmission,  but  also  with  their  capability  to  work  together  to 
achieve  a  common  distributed  task.  In  other  words,  OSI  Is  concerned  with 
cooperation  between  systems,  which  Is  Implied  by  the  expression  "systems 
Interconnection." 
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When  considering  the  overall  services  and  functions  provided  by  the 
seven  layers  of  the  OSI/RM,  we  can  split  the  seven  layers  Into  two  general 
functional  groups: 

e  The  four  lower  layers  {physical,  data  link,  network  and  transport) 
which  together  support  the  end-to-end  data  transport  service  (l.e. 
provide  the  end-to-end  communication  connectivity).  Within  this 
group  can  reside  the  use  of  LAN's,  WAN's  and  Gateways  for 
Interworking. 

e  The  three  upper  layers,  which  Include  the  application  processes 
themselves,  the  presentation  layer,  and  the  session  layer.  The 
latter  two  provide  the  necessary  Beans  and  functions  for  the 
communicating  entitles  to  organize  their  cooperation  by  defining  a 
common  syntax  for  the  Information  exchanged  and  a  means  for 
dialogue  scheduling,  respectively. 

A  system  which  obeys  applicable  OSI  protocol  standards  In  Its 
cooperation  with  other  systems  Is  termed  an  open  system.  The  objective  of  OSI  Is 
to  define  a  set  of  standards  to  enable  open  systems  cooperation  among 
Interconnected  end  systems. 

The  objectives  of  a  closed  architecture,  like  SNA,  and  an  open 
architecture,  like  OSI,  can  be  summarized  as  follows  [20]  and  Illustrated  In 
Figure  5. 3. 1-2. 


Local  system. 

Open  system  interconnection 

,  Local  system 

environment  • 

environment 

'»  ivironment 

Application  1 
processes  ■ 

+  1 
Local  system, 
management! 

1 
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!__ 

_ 1 _ 

'  Application 

■  processes 

1  + 

- j  Local  system 
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i 

jj  Physical  media  ^ 

Figure  5.3.1 -2.  Open  Systems  Interconnections  Between  Closed  Systems 
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•  "SNA  defines  the  Internal  structure  of  a  system.  It  is  concerned 
with  the  cooperation  of  products  to  form  a  coherent  communl cation 
system.  It  also  defines  the  functional  responsibilities  of  each 
network  component  within  a  system,  the  way  Information  Is  exchanged 
between  products,  and,  additionally,  the  internal  control  structure 
that  provides  the  management  of  system  resources  and  system 
services. 

•  OSI  defines  the  external  conmunl cation  capability  of  a  system  to 
make  It  an  open  system,  l.e. ,  capable  of  cooperating  with  other 
open  systems  according  to  OSI  standards.  The  normal  OSI 
applicability  Is  In  cases  where  the  cooperating  open  systems  each 
have  a  different  Internal  architecture." 

"The  advent  of  OSI  standards  will  bring  a  new  dimension  to  the  current 
environment,  by  providing  universally  agreed  upon  means  of  permitting 
communication  and  cooperation  between  £or  among)  heterogeneous  systems  and 
products.  The  existing  systems  will  progressively  Implement  OSI  capability  In 
response  to  user  application  needs.  But  the  existence  of  OSI  standards  should 
not,  and  will  not,  slow  down  the  increasing  number  and  diversity  of  heterogeneous 
systems  and  products.  In  fact.  In  response  to  user's  requirements,  the  systems 
built  on  heterogeneous  architecture  will  grow  In  number  and  size  and  they  will 
even  provide  new  functions  that  are  not  supported  by  OSI  standards.  The  resulting 
OSI  environment  will  therefore  be  characterized  by  a  large,  and  possibly 
Increasing,  diversity  of  heterogeneous  open  systems,  heterogeneous  because  they 
are  built  on  different  architectures;  and  open  because  they  are  capable  of 
cooperating  with  other  systems  by  Implementing  the  OSI  protocols  [85]." 

One  final  observation  about  IBM  SNA's  future  direction  and  relevance  to 
the  LAN  Study  Is  given  In  reference  [83],  SNA  enhancements  now  provide  Advanced 
Program-to-Program  Communication  (APPC).  This  Introduced  a  new  Logical  Unit  (LU) 
type,  called  6.2.,  which  is  referred  to  as  the  APPC.  For  the  first  time,  IBM  In 
SNA  states,  "that  SNA  with  APPC  and  other  SNA  services  can  be  thought  of  as  a 
distributed  operating  system."  In  another  reference  [84],  the  following  Is  stated: 

"From  the  perspective  of  using  application  programs,  SNA  Is  a 
distributed  operating  system;  it  controls  the  execution  of  programs  and  provides 
those  programs  with  services  such  as  allocation  of  distributed  resources, 
input/output  control,  access  security,  and  change  commitment  control  (assurance 
that  all  entered  commands  will  be  carried  out)." 
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IBM's  announced  direction  of  supporting  a  Token  Ring  fora  of  LAM  for 
adding  to  SNA  (86)  Is  another  Important  Industry  Indicator. 

5.4  Command,  Control  and  Communications  for  Tactical  Air  Control  System 

5.4.1  Tactical  Command  and  Control 
Command  and  control  Is  defined*  as: 

"The  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  forces  In  the  accomplishment  of  his  mission." 

Tactical  Command  and  Control : 

1 .  Command 

-  Priorities,  strategies,  weights  of  effort 

2.  Control 

-  Match  weapons  to  targets  according  to  command  level  guidance 

3.  Communications 

-  Internal  to  the  conmand  and  control  structure  Including 
Interfaces  to  strategic  communications 

Hence,  Air  Force  tactical  conmand  control  Is  people,  working  In 
accepted  and  proven  military  organizations,  employing  forces  In  tactical 
environments  -  using  time  proven  methods. 

5.4.2  Discussion 

A  large  number  of  tactical  automated  systems  are  scheduled  for 
introduction  Into  service  In  the  next  decade.  These  systems  will  support 
functions  such  as  sensor  data  processing,  targeting,  weapons  control  and 
logistics.  Emphasis  on  concepts  such  as  beyond-llne-of-slght  target  acqulsltl'-’ 
and  weapon  delivery  techniqes  Is  generating  an  Increasing  requirement  for  fast, 
accurate  exchange  of  Information  across  both  functional  and  service  boundaries. 

Battle  environments  in  which  this  Information  transfer  must  be  able  to 
take  place  will  be  hostile,  dynamic  and  confused.  The  system  users  as  well  as 
critical  elements  of  the  data  distribution  system  will  be  dispersed  for 
survivability.  Communications  connectivities  will  be  continually  changing  because 
of  Jamming,  range  and  Intervlslblllty  considerations.  Exploitation  of  signal 
signatures  and  content  will  be  a  constant  threat;  In  this  environment,  a  shared 
use.  Interconnected,  multiple  link  capability  Is  needed  to  provide  efficient, 
«urv1vable,  Information  transfer  services  for  future  C^I  users. 

"*J£3  KbT 
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AOP  users  frequently  need  high  data  rate  coramunl cation  links,  but 
usually  only  for  short  time  periods.  Because  of  this  bursty  nature  of  the 
traffic,  to  furnish  each  such  user  with  a  separate  channel  would  be  Inefficient 
allocation  of  high  data  rate  communications  link  resources.  Use  of  conventional 
store  ind  forward  data  switches  would  Introduce  unacceptable  time  delays.  Packet- 
switched  networks,  however,  support  this  type  of  tactical  area  communications  need. 
5.4.3  Tactical  Air  Control  Missions  and  Architecture 

A  Tactical  Air  Control  system  can  be  defined  as  the  command  and  control 
elements  that  provide  the  Tactical  Air  Force  Commander  with  decentralized 
execution  of  air  space  control,  area  air  defense,  and  air  offensive  mission 
control.  Mission  functions  performed  would  consist  of  command,  weapons  control, 
surveillance,  movements  and  Identification,  air  space/traffic  control  and  battle 
management.  The  overall  operational  management  would  be  centralized,  but  control 
of  the  execution  would  be  decentralized.  In  order  to  support  such  mission 
operations,  a  robust/survlvable  and  secure  information  exchange  capability  Is 
required. 

During  the  1 980* s,  many  improvements  will  be  made  In  the  Air  Force's 
ability  to  communicate  In  a  battlefield  environment  [87],  Programs  like  JTIDS, 

SEEK  TALK,  TRI-TAC,  and  others  will  Improve  the  security,  jam  resistance, 
connectivity,  and  capacity  of  today's  Air  Force  tactical  communications. 

However,  some  Important  problem  areas  will  remain,  even  after  these  programs  have 
been  implemented.  Of  particular  concern  are  the  survivability  problems  associated 
with  the  enemy's  modern  weaponry. 

The  goal  of  tne  Air  Force's  communications  system  planning  activities 
is  to  reduce  or  eliminate  the  remaining  problem  areas  In  the  1990's.  The  basic 
context  and  overall  C3  architecture  for  the  communications  systems  planning  and 
system  engineering  activities  are  provided  by  the  Master  Plan  for  the  Tactical  Air 
Force's  Integrated  Information  System  (TAFIIS)  [88].  The  plan's  recommendations 
call  for  a  dispersed,  distributed,  survivable  C3  system  for  the  1990's.  The 
plan  developed  the  concept  that  Tactical  Air  Control  air  surveillance  and  control 
assets  should  be  configured  In  a  distributed,  modular  architecture  and  that  the 
sharing  of  Information  was  seen  as  the  key  to  surveillance  and  intelligence 
effectiveness.  To  support  the  distributed  architecture  concept  of  the  TAFIIS  plan, 
a  study  conducted  for  RADC  [89]  recomnended  the  need  for  lightweight,  flexible, 
distributed  Modular  Operations  Centers  called  UK's.  These  NX's  would  be 
Interconnected  together  by  way  of  LAN's  to  form  survivable  command  operations 
centers. 
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The  MQC's  require  the  subdivision  of  the  overall  TAGS  airspace  control 
functions  (Figure  5. 4, 3-1)  Into  subfunctions  which  are  then  distributed  among  a 
configuration  of  Identical  command  and  control  shelters  (Figure  5. 4. 3-2),  called 
the  Comnand  and  Control  Modules  (CCM's).  Interconnectivity  between  CCM's  Is 
provided  by  means  of  a  standardized,  universal  bus  structure. 


single  or  multielement  configuration  (Figure  5. 4. 3-3).  The  CCM's  must  be  easily 
deployable  and  rapidly  relocated  to  match  the  rapid  pace  of  projected  battles.  It 
was  determined  that  a  crew  size  of  four  to  five  people  per  CCM  would  be  optimum 
(Figure  5.4. 3-4).  An  S-28Q  shelter  type  was  selected. 

These  centers  would  be  Interconnected  across  a  battlefield  by  use  of  a 
mixture  of  tactical  Wide  Area  Network  (WAN)  facilities.  Thus,  physical 
distribution  of  resources  employing  networking  Is  Intended  to  reduce  vulnerability 
to  detection.  Increase  survivability  and  an  overall  flexibility.  The  study  made  a 
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determination  of  an  optimum  configuration  for  these  Modular  Operations  Centers 
(MOC's) ,  using  Command  and  Control  Module  (CCM)  building  blocks.  The  CCM's  are  to 
be  designed  to  employ  microcomputer  programming  to  perform  the  functions  of  Weapon 
Control,  Movements  and  Identification,  Air  Traffic  Regulation  or  Battle  Management. 

The  MOC's  should  be  designed  to  Interface  with  a  netted  surveillance 
system  by  means  of  a  wideband  data  bus  through  microcomputer  based  Interface  units 
In  the  CCM's.  Overall,  this  Is  Intended  to  achieve  a  netted  air  surveillance 
system  Internetted  with  a  netted  air  control  system  of  Modular  Operations  Centers. 

The  CCM  would  be  a  general  purpose  operations  shelter  that  houses 
processors,  Integral  communications  equipment,  and  operational  display  positions. 
One  or  more  CCM's  make  up  a  MOC  that  performs  the  TAC's  air  surveillance 
management  and  control  mission.  A  CCM  Is  to  handle  up  to  five  operator  ~>o$1t1ons 
(Table  5.4.3  and  Figure  5. 4. 3-5).  A  member  of  the  D00  standard  military 
microprocessor  family  Is  to  be  employed  and  programmed  In  the  standard  00D  higher 
order  language,  Ada.  Within  the  shelter,  the  processing  functions  are  Interfaced 
via  an  Internal  bus  structure. 
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Figure  5. 4. 3-3.  TACS  Modular  Operations  Concept  Example  Deployment 
5.5  Command  Control  and  Communications  for  the  Tactical  Army  System 

A  review  was  conducted  of  the  architectural  description  [90]  of  a  C 
system  to  meet  requirements  of  the  Tactical  Arroy-AI  r/Land  Battle  2000  concept. 

The  findings  were  very  similar  to  those  recommended  In  the  Air  Force  TAFIIS  Master 
plan  In  the  following  aspects: 

e  Basic  requirement  to  provide  a  high  degree  of  survivability  and 
continuity  of  operations  Is  essential  for  execution  of  the  alr/lanci 
battle. 

e  Intended  to  be  a  distributed  tactical  command  and  control  system. 

e  Distributed  processing  was  seen  needed  among  the  battlefield  s 
automated  systems. 

e  Command  posts  must  be  geographically  or  physically  dispersed. 

e  Certain  data  bases  need  to  be  dispersed  and  replicated. 

•  Alternate  and  backup  operations  needed. 

•  System  concepts  Involve  the  dispersal  and  Interconnection  of 
command  cells. 
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Figure  5. 4. 3-4.  Command  and  Control  Module  (CCM)  Shelter  Layout  Concept 
5.5.1  General  Network  Architecture 

The  network  architecture  Is  layered  to  enhance  survivability  and 
mobility.  The  basic  subsystems  are  the  subordinate  systems  connected  by  the 
command  post  network  CPN.  They  constitute  the  bottom  layer. 

This  lowest  level  subsystem  Is  a  cell  of  the  cellular  conmand  post  and 
consists  of  one  or  more  collocated  processor  elements  (e.g..  In  a  single 
trailer).  The  CPN  Is  a  local  area  network  (max  distance  between  elements  1-10  KM) 
linking  together  a  set  of  subordinate  systems  and  a  control  element.  The  control 
element  Is  also  a  cell  of  the  CCP  formed  by  processor  elements.  It  controls  the 
CPN  and  provides  the  gateway  capabilities  to  allow  attachment  to  the  backbone 
network. 

The  subsystems  of  the  higher  layers  are  configured  In  the  following 

manner: 
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Table  5.4.3.  Modular  Operations  Center  (HOC)  Operational  Staffing  Positions 

letter 


Section 

Position 

Designator 

AFSC* 

Command 

Battle  Commander 

BC 

1716 

Operations  Officer 

DO 

1716 

Senior  01  rector 

SD 

1716/1744 

Intelligence  Officer 

INTEL 

8054/1744 

NCOIC  of  Operations 

NCUI C/OPS 

27690 

Battle  Staff  Technician 

BST 

27690 

System  Control  Technician 

SCT 

27650 

Weapons 

Weapons  Assignment  Officer 

WAO 

1744 

Offensive  Mission  Coordinator 
Air  Defense  Artillery  Fire 

OMC 

1744 

Coordinating  Officer 

AD AFC 0 

Army 

Weapons  Assignment  Technician 

WAT 

27670 

Senior  Weapons  Controller 

SWC 

1744 

Weapons  Controller 

WC 

1744 

Weapons  Control  Technician 

WCT 

27650 

Surveillance 

Air  Surveillance  Officer 

ASO 

1744  or  27690 

Management 

Air  Surveillance  Technician 

AST 

27670 

Data  Quality  Monitor 

DQM 

1744  or  27690 

Track  Monitor 

TM 

27630 

Status  Technician 

ST 

27630 

Identification 

Identification  Offlcler 

IDO 

1744 

Identification  Supervisor 

IDS 

27670 

Identification  Technician 

IDT 

27650 

Air  Movement  Technician 

AMT 

27630 

Manual  Input  Technician 

MT 

27630 

Air  Traffic 

Senior  Controller 

SC 

1 744/1 6XX 

Regulation 

Air  Traffic  Controller 

TC 

27250 

Center  (ATRC) 

Flight  Data  Coordinator 

FDC 

27250 

Component  Services 
Section  (CSLS) 

Army  Flight  Operations  Center 
Representatl ve 

FOC/R 

Army 

Navy  Combat  Information  Center 
Representative 

CIC/R 

Army 

Marine  Tactical  Air  Operations 
Center  Representative 

TAOC/R 

Marl ne 

Operations  Coordination 
Technician 

OCT 

27670 

*A1r  Force  Specialty  Code 
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Figure  5. 4. 3-5.  Maximum  Modular  Operations  Concept  (MX)  Configuration 
•  Subsystems  of  a  given  layer  are  linked  together  by  a  network  to 
form  a  subsystem  of  the  next  higher  layer.  Each  subsystem  contains 
a  control  element  that  may  or  may  not  be  distributed.  The  control 
element  provides  management  of  the  subsystem  network  and  an 
Interface  to  a  higher  level  network. 

This  layered  structure  conforms  to  the  Army  command  structure.  The 
architecture  Is  designed  to  build  subsystems  with  high  Intra-  but  low 
Inter-subsystem  traffic. 

5.5.2  Subsystem  Architecture 

The  system  contains  two  basic  types  of  networks;  the  conmand  post 
network  and  the  backbone  network. 

a.  Command  Post  Network  -  This  is  designed  around  a  local  area  network 
In  a  way  transparent  to  Its  users.  It  maintains  autonomy  over  its 
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local  functions,  can  function  alone  or  as  an  attached  element  of 
the  overall  network.  The  logical  structure  Is  a  bus  broadcasting 
network. 

b.  Backbone  Network  -  This  comprises  the  three  higher  layers  of  the 
network.  Short-,  medium-  and  long-haul  networks  are  utilized. 

Each  of  these  networks  can  function  Independently  and  has  Its  own 
control  element.  Communications  medium  will  likely  be  radio,  satellite 
and  terrestrial  networks,  such  as  TRI-TAC,  public  network  and  telephone 
lines. 

5.6  Distributed  Information  Proce«s1ng  for  Command,  Control  and 

Communications 

5.6.1  General 

This  subsection  reports  on  two  aspects  of  distributed  Information 

3 

processing  for  C  ;  what  the  Identified  requirements  were  and  what  were  the 
recognized  characteristics  and  criteria  for  structuring  a  system  architecture  to 
satisfy  those  requirements.  Both  are  discussed  In  the  succeeding  paragraphs. 

5.6.2  Requirements  for  C  Distributed  Information  Processing 
Reference  [74],  as  discussed  In  Paragraph  5. 1.1.1,  presented  a  high 

level  view  of  an  architecture  for  C3,  In  that  the  following  broad  distributed 
information  processing  requirements  were  stated: 

e  Command  and  control  functionality  should  be  layered  (see  Figure 
5.1. 1.1). 

e  Many  dissimilar  processors  need  to  be  supported. 

•  Distributed  resources  should  be  capable  of  communicating  over  wide 
area  networks  employing  high  level  protocols  and  packet-switching. 

e  Processing  resources  will  be  distributed  across  the  battlefield. 

•  The  processors  must  support  not  only  specific  user  applications, 
but  high-level  network  protocols  as  well. 

•  The  system  must  be  designed  to  support  an  environment  whereby 
backup  resources  are  automatically  assigned  in  the  event  of  a 
primary's  failure. 

•  User  Information  must  be  redundantly  maintained  (for  survivability). 

•  Decisions  on  where  the  resources  are  available  to  support  needed 
functions,  and  on  that  assignment  must  be  accomplished 
automatically. 
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•  A  distributed  Internetwork  operating  system  Is  required. 

•  A  set  of  generic  C2  software  utilization  Is  required,  which  also 
may  need  to  be  distributed  (such  as  distributed  data  base 
management  systems,  electronic  mall  systems,  graphics  systems  and 
distributed  teleconferencing  systems). 

•  Automated  network  management  Is  needed. 

•  Finally,  applications  software  must  be  built  to  support  specific 
C‘  functions  (such  as  automated  force  status  reporting  and 
support  for  automated  sensor  correlation  and  logistics  planning). 

5. 6. 2.1  Strategic  Command,  Control  and  Communications  Application  Characteristics 

Reference  [34]  classified  strategic  command  and  control  applications 
Into  the  following: 

1.  Real-Time  Applications 

Applications  that  cannot  perform  their  function  If  network  delay 
exceeds  a  certain  value.  Some  applications  will  fall  Into  this 
category. 

2.  Applications  That  Can  Tolerate  Delay 

This  Includes  Interactive  applications  Involving  user  terminals, 
where  user  satisfaction  drops  when  delays  Increase  above  very  small 
values.  A  large  number  of  applications  are  seen  as  falling  Into 
this  category. 

3.  Applications  That  Are  Relatively  Insensitive  to  Network  Delay 
This  Includes  batch  processing,  flla  transfer  and  electronic  mall 
applications  where  throughput  Is  more  Important  than  low  delay. 
Network  delay  typically  forms  only  a  minor  portion  of  the  total 
delay  experienced  by  these  applications.  A  sizeable  portion  of  the 
applications  are  seen  falling  Into  this  category. 

4.  Applications  Sensitive  to  Variations  In  Delay 

Some  applications,  such  as  digitized  voice,  require  minimal 
variation  In  the  delays  experienced  by  the  Individual  packets  being 
received  In  the  data  stream.  A  certain  amount  of  fixed  delay  Is 
acceptable,  but  the  variation  must  be  held  within  limits.  This 
will  comprise  a  small  portion  of  the  applications.  Digitized  voice 
reliability  requirements  are  less  than  for  digital  data  because 
Information  quality  Is  not  significantly  degraded  by  small  data 
losses  or  errors. 
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Types  are  classified  by  [34]  as  follows: 

1.  Olgltal  Data 

This  will  be  exchanged  between  the  communicating  host  dat& 
processors,  the  gateways  and  user  terminal s/worlc  stations.  This 
data  Is  characterized  as  follows: 

a.  Message  Transfer  -  short  transactions  of  a  few  thousand  bytes 
or  less.  Applications  Include  terminal -to-host, 

terminal -to- terminal ,  and  terminal -to-gateway  (distant  host) 
interactions. 

b.  Bulk  Data  Transfer  -  file  transfers,  other  stream  traffic. 
Applications  Include  data  base  processing  and  archiving,  and 
Interprocess  communications  between  hosts. 

2.  Voice  -  A  secure  voice  capability  Is  seen  as  being  required.  This 
will  consist  of  Intercom  and  teleconferencing.  This  will  require 
low  delay  plus  controlled  delay  variance.  In-sequencing  delivery 
but  not  stringent  reliability. 

3.  video  -  Video  displays  and/dr  teleconferencing  will  be  required. 
Secure  video  requires  encryption,  high  data  rates  and 
connection-oriented  protocol.  Absolute  reliability  for  digitized 
video  Is  not  essential. 

4.  imagery  -  Included  here  are  facsimile,  slow-scan  video,  and  raster 
graphics.  Substantial  bandwidth  may  be  required,  but  the  delay 
requirements  are  not  normally  as  strict  as  for  video  and  voice. 
Reliability  requirements  are  not  as  strict  as  those  for  digital 
data  In  terminal  or  file  transfer  applications. 

5.  Non-Digital  Devices 

A  LAN  architecture  that  Includes  video  and  voice  channels  would 
facilitate  the  development  of  multimedia  applications.  The 
following  are  possible  ways  for  Incorporating  voice  and  video 
devices  Into  the  LAN: 

a  Employ  separate,  dedicated  or  switched  point-to-point  channels, 
e  Digitize  analog  form  Information  and  transmit  with  the  data, 
e  Employ  protocols  differing  from  digitized  data  to  exploit  the 
different  reliability  and  delay  requirements. 

Several  types  of  networking  services  and  protocols  were  Identified  by 
[34],  The  services  are  as  follows,  while  the  main  protocols  are  Identified  by 
Figure  5.6. 2. 2: 
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Figure  5. 6.2.2.  Command  Center  Protocol  Architecture 

•  Terminal -to-termlnal  conmunl cations  up  to  19.2  kb/s 

•  Virtualization  of  terminal  characteristics 

•  Inexpensive  te.mlnal  Interfaces 

•  Computer-to-computer  communication  in  the  megabit  range 

•  High-speed  computer  Interfaces  with  minimal  Impact  from  networking 
software 

•  Transaction  services  (datagrams) 

•  Virtual  circuits  (Initiation,  termination,  and  control  ofl 

•  End-to-end  flow  control  (Includes  speed  matching) 

•  Error  control  (ensuring  accurate  data  transmission) 

•  Equipment  Interfacing  (code  translation,  terminal  translation,  etc.) 

•  Internetwork  ng 

This  set  of  services  was  grouped  Into  three  categories,  based  upon  a 
migration  ranging  from  a  basic  through  a  mid-level  and  reaching  an  advanced 
capability.  These  are  as  follows: 

Basic  Requirements 

Hundreds  of  terminals  of  va.ylng  types  and  tens  of  heterogeneous 
computers  need  to  be  Interconnected.  The  computers  may  range  from  microcomputers 
to  large  systems  scattered  throughout  a  command  center.  Local  terminal -to-host 
communications,  with  speeds  up  to  19.2  kb/s,  will  need  support.  Local 
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computer-to-computer  comraunl cations,  with  data  rates  of  Billions  of  bits/sec,  will 
also  need  support. 

Hlo-Levei  Requirements 

High-speed  multiplexed  Interfaces,  capable  of  supporting  many  varying 
connections  within  a  host  computer,  need  to  be  provided.  Network-specific 
software  needs  to  be  offloaded  from  the  host  computers  by  use  of  a  host  front-end 
processor.  Mechanisms  need  to  be  provided  to  allow  access  to  remote  applications, 
data  bases  and  flies.  A  textual  electronic  message  facility  needs  to  be  provided. 

Advanced  Capability  Requirements 

Load-leveling  and  other  resource  sharing  concepts  need  to  be  employed 
to  efficiently  utilize  resources  and  minimize  delay  during  day-to-day  and  crisis 
operations.  Name  servers  need  to  be  utilized  to  eliminate  the  need  to  know  the 
physical  location  (l.e. ,  net/host)  of  data  bases,  standard  command  center 
application  programs,  software  tools,  or  user  mailbox.  Support  Is  needed  for  the 
preparation  and  transmission  of  documents  with  pictorial  material,  as  well  as 
text,  and  provide  high  quality  printed  output.  The  exchange  of  critical 
multimedia  message  (l.e.,  voice,  pictorial,  textual)  with  multi  precedence  levels 
needs  supporting.  Lastly,  teleconferencing  Is  needed  to  support  Interactions 
among  multiple  entitles. 

5. 6. 2. 2  Tactical  Distributed  Processing  Summary  Requirements  [23] 

Automatic  data  processing  requirements  Include  the  following  minimum 

areas: 

1.  Surveillance 

2.  Command 

3.  Weapons  Control 

4.  Identification 

5.  Air  Traffic  Regulation 

6.  Other 

-  Simulation 

-  Support 

-  Liaison 

Data  processing  functions  fall  Into  the  following  areas: 

1.  Composition  and  editing  of  data 

2.  Searching  for  data  records 

3.  Definition/maintenance  of  data  base 

4.  Retrieve.',  and  output  of  data 

5.  User  to  user  data  exchange 

6.  User  aids/computation 
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Components  of  a  TAFIIS  Data  Processing  System  Architecture  are  the 

to! lowing: 


1*  Processor  and  peripherals 

2.  Coraraunl cation  devices 

3.  User  terminals 

4.  Operating  system  software 

5.  System  software 

6.  Application  software 

Figure  5. 6. 2. 2-1  provides  a  logical  view  of  the  TAFIIS  architecture. 
Components  of  a  distributed  processing  architecture  are: 

1.  Users:  analyst  and  system  support  classes 


2.  Processing  cell  of  collocated  processors 

3.  MINI NET  network  conmunl cations  Interconnecting  processors  Into  a 
cell 

4.  MAXINET  network  communications  internetting  the  cells 

5.  Operating  System  hierarchical  elements: 

Local  (constituent,  or  COS) 

-  MININET  functions  (or  MINIDOS) 

-  MAXINET  functions  (or  MAXIDOS) 


6.  Functional  software  components 

7.  Data 

Objectives  of  a  distributed  processing  architecture  are: 

1.  Geographical  dispersal  of  cells 

2.  Flexible  capacity  through  multiple  processors 

3.  Survivability 

4.  Security  of  data  and  activity 

5.  Modularity 
Sizing  Is  as  follows: 

1.  Cells  -  tens 

2.  Users  -  hundreds 

3.  Communications 

•  Long  haul:  links  hundreds  of  km  long 

•  Local:  links  In  the  0.1-1  km 

A  physical  view  of  the  TAFIIS  data  processing  architecture  Is  shown  1 
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Figure  5.6. 2. 2-1.  Logical  View  of  the  TAFIIS  Architecture 
The  overall  architecture  Is  as  follows: 

1.  Clusters  or  cells  of  tightly  coupled  processors  In  a  local 
geographical  proximity  [23,  p.  4-1], 

2.  Internetting  of  cells  by  a  relatively  low  bandwidth  network. 

3.  Geographical  distribution  of  C  functions  of  an  automated  system. 

4.  Interconnection  of  cells  Is  necessary  In  order  to  share  data  and 
assure  survivability  of  critical  Information. 

5.  Choice  of  tightly  coupled  local  cell  of  processors  based  on  high 
common  Interest  among  local  users  In  data  sharing,  processing  and 
Information  resources  In  close  physical  proximity. 

t'.  Choice  of  loosely  coupled  Internet  of  cell  clusters  based  on  lower 
levei  of  conwon  need  for  sharing  processing  resources  and  more  for 
accessing  a  global  data  base  management,  categorized  by: 

•  Data  retrieval  of  Information  elements  between  cells 

•  Update  of  other  cell  elements,  particularly  for  backup  purposes 

•  Data  base  segment  recovery 

7.  Cell-to-cell  Interconnectivity  will  exhibit  outages,  errors,  and 
delays  to  the  extent  where  each  cell  needs  to  exhibit  a  large 
degree  of  functional  autonony.  This  results  In  the  global  set  of 
cells  forming  a  "cooperative  federation"  of  processing  elements. 
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Figure  5.6. 2. 2-2.  Physical  View  of  the  TAFIIS  Data  Processing  Architecture 

Cell  architecture  Is  comprised  of  the  following: 

1.  A  MININET's  cell  Is  the  unit  recognized  by  the  MAXIDOS. 

2.  Cell  comprises  all  resources  Interconnected  by  a  single  local  bus. 

3.  Hardware  components  In  a  cell  will  be  heterogeneous. 

4.  Program  and  data  within  a  MININET  can  be  adapted  for  local 
performance  needs. 

5.  Programs  and  data  within  a  MAXINET  will  have  a  generic  form  for 
transmission. 

MAXINET  logical  functions: 

1.  Addresses  the  Issue  of  critical  information  flow  and  supports 
system  goals  of  mobility  and  survivability 

2.  Recognizes  units  of  MIN I NETS 
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TAFIIS  structured  Information  types  would  comprise  the  following: 

1.  Record  messages 

2.  Data  bases 

3.  User-to-user  messages 

4.  User  Interface  language 

5.  Software 

6.  System  configuration  tables 

7.  Performance  data 

8.  System  messages 

The  distributed  operating  system  treats  all  types  of  data  as  a  message 
l.e. ,  a  stand-alone  unit  of  Information.  Figure  5.6. 2. 2-3  Illustrates  a  user 
Interface  architecture. 
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Figure  5. 6. 2. 2-3.  Conceptual  User  Interface  Architecture 

Resource  Management  consists  of  the  following: 

1.  Global  resources  management  via  the  MAXIDOS  through  the  MAXINET  Is 
probabilistic.  It  operates  under  conditions  of  Imperfect, 
Incomplete  and  Inconsistent  state  observations  made  by  a  number  of 
loosely  coupled  MAXIOOS  decision  makers  located  In  each  cell. 

2.  The  TAC  C3  environment  precludes  two  or  more  cells  of  the  MAXIDOS 
from  being  able  to  develop  a  consensus  before  an  actual  resource 
allocation  Is  made. 
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3.  Each  cell's  allocation  procedures  must  make  Independent  assessments 
of  the  state  of  the  distributed  system  to  arrive  at  control 
decisions. 

4.  Each  cell  can  request  status  Information  from  other  cells  to 
attempt  to  determine  a  more  accurate  estimate  of  system  state. 

5.  In  the  absence  of  good  system  state  status,  a  cell  exercises 
Independent  decision  making. 

6.  The  resulting  control  scheme  is  highly  decentralized  as  there  are 
multiple  Independent  decision  makers. 

7.  Each  cell,  also,  controls  only  a  partial  set  of  the  total  amount  of 
system  (global)  resources. 

8.  At  the  MIN I NET  cell  level,  the  resource  management  approach  Is 
highly  dependent  cn  the  nature  of  the  mission  performed  by  the  cell 
and  has  been  left  unspecified.  However,  intracell  resource 
management  algorithms  will  be  based  on  control  principles  requiring 
high  coordination  between  the  allocation  procedures  resident  at 
multiple  processing  elements. 

9.  Therefore,  Intracell  processing  will  feature  centralized  control 
procedures  with  a  resultant  ability  to  assure  data  consistency  ar.d 
high  level  adaptive  performance  of  computation  tasks. 

Security  considerations: 

1.  The  tactical  system  environment  requires  for  the  generation, 
storage,  processing  and  transfer  of  Information  elements  of  diverse 
levels  of  security  classification. 

2.  Further,  tactical  Information  must  be  accessed  by  users  at  multiple 
levels  of  clearance. 

3.  The  proposed  security  concept  relies  on  these  concepts: 

a.  Each  cell  Is  responsible  for  performing  user  authentication  In 
a  well  defined,  dynamically  reactivated  procedure, 
h.  Intercell  Information  transfer  employs  cryptographic  protection, 
c.  Cryptographic  schemes  are  varied  dynamically  with  time. 

Configuration  Management  Characteristics: 

1.  The  Information  procuring  system  needs  to  deploy  a  system  capable 
of  continuous  and  efficient  reconfiguration  of  i*s  processing, 
storage  and  communications  resources. 

2.  Reconfiguration  needs  exist  both  at  the  cell  and  global  levels. 
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3.  MAX IDOS  oust  be  concerned  with  global  management  of  unreliable 
resources  through  unreliable,  noisy,  low  capacity  channels. 

4.  MINIDOS  can  assume  availability  of  all  Its  local  cell  resources  and 
can  assume  a  correct  view  of  cell  status. 

Data  Base  Management  Elements: 

1.  Data  base  management  responsibilities  are  broken  down 
hierarchically  at  the  global  and  local  cell  levels. 

2.  At  the  global  level,  probabilistic  mechanisms  are  needed. 

3.  At  the  local  level,  more  deterministic  mechanisms  are  needed. 

4.  A  high-level  Information  (rather  than  data)  oriented  language  at 
the  global  level  Is  proposed  to  exchange  uniform  messages  between 
homogeneous  cells. 

5.  Within  cells,  translatlon/converslon  schemes  are  needed  to  handle 
heterogeneous  processors. 

Interprocessor  Communication  considerations  are  ?$  follows: 

1.  Assumed  that  the  Intercell  MAXINET  i,el1es  on  use  of  electromagnetic 
links,  which  must  be  shared  with  other  distributed  tactical 
resources.  These  are  subject  to  failure,  damage.  Interference  or 
destruction. 

2.  Average  MAX  I  NET  available  bandwidth  assumed  to  be  10-50  kb/s. 

3.  Cell  Interfaces  with  the  MAXINET  are  to  present  a  homogeneous  Image. 

4.  Each  cell  maintains  a  status  map  of  conditions  of  other  ceils  and 
links  through  the  MAXINET. 

5.  It  Is  desired  that  Intercell  cotimunicatlons  employ  a  common 
language  (protocol)  designed  to  support  distributed  data  management 
functions,  such  as: 

•  Data  base  element  creation/modification/update 

•  Data  base  element  availability  verification 

6.  Cells  are  to  comnunlcate  a  high  level  by  means  of  a  common 
cell-to-cell  language  and  are  not  to  need  to  consider  the  Internal 
operation  of  other  cells. 

7.  MAXIDOS  to  adopt  an  "Intelligent  gateway"  and  Its  common 
tactical -data  oriented  language  to  achieve  Interoperability. 

8.  Intracell  MININET  Interprocessor  comnunl cations  need  to  support 
interfacing  heterogeneous  processors.  The  following  will  need  to 
be  done: 
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•  Reformatting/translation  of  bit  strings  elements  between 
heterogeneous  processors. 

•  Reformatting/transl?tion  of  operating  system  level  requests 
between  heterogeneous  processors  or,  alternatively,  translation 
of  such  requests  to  a  common  Interprocessor  language. 

Protocols  [90]  are  needed  to  create  a  virtual  network  on  top  of  the 
basic  physical  network.  They  will  serve  two  purposes: 

•  Facilitate  the  transmission  of  data  and  control  messages  among  the 
subsystem. 

#  Serve  network  control  In  resource  allocation,  status  monitoring 
configuration  and  reconfiguration  of  the  network. 

Protocols  provide  for  standard  Information  exchange  messages  between 

processes. 

a.  Data  Transmission  Protocols 

These  should  be  compatible  with  the  ISO  OSI/RM. 

b.  Network  Control  Protocols 

1 .  Configuration  Protocols 

These  support  network  configuration  and  two  are  Identified. 

a)  Acceptance  -  used  between  operating  systems  when  a 
subsystem  Is  attached  to  a  higher  level  network. 

b)  Exit  -  used  when  a  subsystem  Is  detached  from  the  higher 
level  network. 

2.  Status  Monitoring  Protocols 

These  monitor  the  status  of  the  various  subsystems  and 
communication  links. 

3.  Contingency  Handling  Protocols 

These  are  used  whenever  reconfiguration  Is  needed  as  a  result 
of  orderly  detachment  of  units  or  as  result  of  a  temporary  or 
permanent  loss  of  resources  or  communication  links. 

Operational  military  command  and  control  organizations  are  looking  to  local  area 
network  technology  to  provide  connectivity  among  the  dispersed  data  processing 
elements  within  their  respective  organizations.  Protocol  layers  1-4  provide 'this 
basic  connectivity.  The  higher  layer  protocols,  layers  5-7,  however,  are  the  ones 
needed  to  support  the  desired  functional  Integration  for  distributed  Information 
processing  operations.  Protocols  are  needed  for  the  following  data  processing 
functions: 
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•  File  transfer 

•  Distributed  data  base  access  and  update 

•  Resource  management 

•  system  resource  monitoring 

•  System  fault  tolerance/survlvablllty 

•  Interactive  access  to  distributed  processes 

•  Plus  others 

5.6.3  Distributed  Processing  Architectural  Criteria 

Enslow  [26,  91]  has  set  forth  some  basic  criteria  which  a  system  must 
possess  In  order  to  be  considered  a  Fully  Distributed  Processing  System  (FDPS). 

"A  FDPS  [91]  conceptually  consists  of  a  loosely  coupled  network  of 
Independent  machines.  Each  machine  Is  capable  of  communicating  with  other 
machines  and  controls  a  set  of  local  physical  and  logical  resources  (e.g., 
processors,  memory,  files,  devices,  etc.).  The  machines  are  autonomous  In  that 
each  processor  or  server  has  final  responsibility  for  the  control  of  the  resources 
It  provides.  A  layer  of  control  Is  Imposed  on  this  network  of  machines  to  achieve 
unification  of  resources,  cooperation,  and  system  transparency.  It  Is  assumed 
that  all  macnlnes,  while  retaining  their  autonomy,  follow  a  common  master  plan  to 
attain  effective  cooperation  between  the  loosely-coupled  logical  as  well  as 
physical  resources." 

The  RAO  definition  has  five  components: 

1.  A  multiplicity  of  general-purpose  resource  components 

2.  A  physical  distribution  of  these  physical  and  logical  components 

3.  A  high-level  operating  system 

4.  System  transparency 

5.  Cooperative  autonomy 

Multiplicity  of  General  Purpose  Resource  Components 

System  services  are  provided  by  a  multiplicity  of  resource  components 
that  may  be  assigned  tasks  to  perform.  It  is  necessary  that  the  system  have  the 
ability  to  be  dynamically  reconfigured  on  a  short-term  basis,  with  respect  to 
those  resources  that  provide  specific  services  at  any  given  time. 

Physical  Resource  Distribution  Through  Interconnecting  Networking 

Physical  resources  are  distributed.  They  cooperate  to  provide  service 
to  users  through  the  exchange  of  messages,  following  rules  of  protocol.  The 
Interconnection  comprises  networking,  connecting  peer  level  resource  components 
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together.  The  criteria  for  autonomous  operation  of  processes  makes  use  of 
Information  transfers,  such  as  status,  requests  for  service,  synchronization 
between  logical  resources,  and  so  on. 

A  High  Level  Operating  System 

A  well  defined  set  of  policies  and  mechanisms  Is  needed  to  govern  the 
global  operations  for  the  user  services  and  resource  providers.  There  must  be  no 
strong  hierarchy  existing  between  the  high-level  and  local  operating  systems.  The 
local  operating  systems  need  not  be  homogeneous. 

System  Transparency 

The  Interface  presented  to  the  user  must  be  one  of  services  and  not 
that  of  servers.  The  existence  of  a  distributed  operating  system  Is  to  be  totally 
transparent  to  the  user. 

Cooperative  Autonomy 

The  operations  of  all  components  or  resources,  both  physical  and 
logical,  are  to  be  very  autonomous.  Message  passing  network  protocols  are  to  be 
structured  to  support  peer-to-peer  Interactions,  with  the  right  of  one  to  refuse  a 
request  for  service  from  another. 

In  addition,  Cypser  [92]  set  forth  certain  criteria  which  governs  the 
distribution  of  functions.  First,  he  Identifies  six  functions  which  are 
distributable,  to  be  as  follows: 

Six  Distributable  Functions 

1.  Management  of  application  processing 

2.  Management  of  the  data  that  may  be  sto»ad  on  a  hierarchy  of  storage 
devices 

3.  Management  of  communications 

4.  User  application  programs 

5.  Application  subsystems 

6.  Input/output  mechanisms 

Next  he  states  that: 

“A  distributed  function  exists  if  either: 

1.  The  same  function  can  be  executed  at  more  than  one  node  In  a 
network  and/or 

2.  The  function  Is  not  completely  executable  in  a  single  node  and 
parts  of  that  function  are  executed  cooperatively  In  separate  nodes" 
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And  lastly: 

"A  distributed  function  must  have  the  following: 

1.  Information  needed  by  function 

2.  Decision  logic  for  function 

3.  Executabllity  of  function 

4.  Invokabillty  from  another  node" 

5.7  Operating  Systems  for  C  Distributed  Information  Processing 

One  of  Enslow's  criteria  for  a  FDPS  [26,  91]  calls  for  use  of  a  high- 
level  operating  system  In  such  a  manner  as  to  tie  Into  a  global  network  the 
collection  of  Individual,  probably  heteroganeous,  local  operating  system 
machines.  What  is  an  operating  system? 

5.7.1  An  Operating  System 

The  set  of  programs  {software/firmware)  that  make  the  physical /logical 
resources  of  the  system  usable  Is  considered  the  operating  system.  It  Is 
primarily  a  resource  manager  for  managing  processors,  storage.  Input/output 
devices,  and  data.  An  operating  system.  In  addition  to  managing  the  system 
resources,  provides  services.  First,  It  provides  services  to  Internal  system 
users,  and,  secondly.  It  provides  services  to  external  system  users.  See  Table 
5.7.1.  Two  major  forms  of  operating  systems  were  Identified  In  previous  studies 
as  being  required  to  construct  a  distributed  processing  system  [23,  24,  27,  28, 

29,  93],  One  Is  the  original  nondlstributed  operating  system,  called  the  Local  or 
Constituent  Operating  System  (LOS  or  COS).  The  second  Is  the  global  network-wide 
operating  system.  This  latter,  further,  has  been  viewed  as  being  structured  In 
two  different  ways;  one,  call  a  Network  Operating  System  (NOS)  and  the  other  a 
Distributed  Operating  System  (DOS),  and  may  employ  homo  or  neterogeneous  OS's. 

a.  Nondlstributed  (Local) 

This  Is  the  existing  vendor-supplied  OS  referred  to  as  a 

Constituent  (or  local)  Operating  System  (COS). 

b.  Network-Wide  Operating  Systems  (Global) 

Two  forms  were  identified: 

e  Network  Operating  System  (NOS) 

•  Distributed  Operating  System  (DOS) 

•  They  comprise  a  collection  of  software  and  associated  protocols 
that  allows  a  set  of  antonomous  computers;  which  are 
interconnected  by  a  computer  network,  to  be  used  together  In  3 
convenient  and  cost-effective  manner. 
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Table  5.7.1.  Hierarchical  Classification  of 
Operating  System  Services 


1.0  SERVICES  TO  PROCESSES 

1.1  Process  Management 

1.1.1  Process  Initiation 

1.1.2  Process  Termination 

1.1.3  Error  Recovery 

1.1.4  Interprocess  Mediation 

1.1. 4.1  Priority  Assignment  and  Management 

1.1. 4. 2  Coordination  Primitives 

1.1. 4. 3  Communication 

1.1.5  Environment  Management 

1.1. 5.1  Storage  Management  (for  specific  processes) 

1.1. 5. 2  Exceptional  Condition  Management 

1.1. 5. 3  “Privileged-  Process  Services 

1.1. 5. 4  Process  Limit  Monitoring 

1.2  Resource  Management 

1.2.1  Processor 

1.2. 1.1  Scheduling,  Conflict  Resolution,  Deadlock 
Prevent!  on 

1.2. 1.2  Allocation 

1.2. 1.3  Protection 

1.2. 1.4  Error  Detection  and  Recovery 

1.2.2  Timing  Services 

1.2. 2.1  Scheduling,  Conflict  Resolution,  Deadlock 
Prevention 

1.2. 2. 2  Allocation 

1.2. 2. 3  Protection 

1.2. 2. 4  Error  Detector  and  Recovery 

1.2.3  Main  Storage  Management  Global  Resource  Management 

1.2. 3.1  Partitioning 

1.2. 3. 2  Segment  Control 

1.2.4  Secondary  Storage  Management  (Global  Resource  Management) 
1.2. 4.1  Scheduling,  Conflict  Resolution,  Deadlock 

Prevention 
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Table  5.7.1.  Hierarchical  Classification  of 
Operating  System  Services  (Continued) 

1.2. 4. 2  Allocation 

1.2. 4. 3  Protection 

1.2. 4. 4  Error  Detection  and  Recovery 

1.2. 4. 5  Oevlce  Access 

1.2. 4. 6  Physical  File  System 

1.2. 4. 7  Process  Backing  Store 

1.2.5  I/O  Devices 

1.2. 5.1  Scheduling,  Conflict  Resolution,  Deadlock 
Prevention 

1.2. 5. 2  Allocation 

1.2. 5. 3  Protection 

1.2. 5. 4  Error  Detection  and  Recovery 
2.0  SERVICES  TO  USERS 

2.1  System  Command  Languages 

2.1.1  System  Operator 

2.1.2  Online  User 

2.1.3  Batch  User 

2.2  Data  Operations 

2.2.1  File  System  Manipulation 

2.2.2  Data  Generation  and  Modification 

2.2.3  Output  Aids 

2.3  Program  Generation  and  Invocation 

2.3.1  Design  Aids 

2.3.2  Compilers  and  Interpreters 

2.3.3  Linkers 

2.3.4  Library  Maintenance 

2.3.5  Debugging  Tools 

2.4  System  Management  Support 

2.4.1  System  Generation  and  Configuration 

2.4.2  System  Initiation 

2.4.3  System  Backup  and  Recovery 

2.4.4  Accounting  and  Auditing 

2. 4. 4.1  Accounting  Cost  Control 

2. 4. 4. 2  Audi ting/Survell lance 

2.4.5  Performance  Monitoring  and  Tuning 
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A  significant  difference  In  distinguishing  between  the  NOS  and  DOS 
forms  Is  based  on  the  degree  of  autonomous  control  versus  global  control.  That 
Is,  In  an  NOS  all  of  the  processors  are  Independent  from  a  process  scheduling 
point  of  view,  whereas  In  a  00S  the  processors  do  not  act  Independently  but  In 
accordance  with  a  global  control  strategy  and  some  global  control  synchronization. 

Before  discussing  each  of  these  further,  a  new  concept  In  structuring 
of  operating  systems  needs  to  be  Introduced.  This  Is  referred  to  as  the  object 
model  or  object  oriented  design.  The  following  summarizes  the  object  oriented 
model  concept: 

Object  Based  Operating  System  Architecture 

a.  Object  oriented  design  Is  a  design  process  which  deals  with 
abstract  (high-level)  objects  and  operations  performed  on  these 
objects. 

b.  Defines  an  abstract  machine  composed  of  abstract  resources 
(objects)  that  are  manipulated  by  processes  to  protect  the  use  of 
resources,  to  assure  coherence,  and  to  Impose  policies  of  economic 
use. 

c.  A  resource  Is  an  abstraction  that  Is  defined  to  the  system  and 
given  a  set  of  attributes  relating  to  the  accessibility  of  the 
resource  and  Its  physical  representation  in  the  system. 

d.  A  complete  operating  system  Is  seen  as  a  set  of  procedure  objects 
and  a  set  of  data  objects  In  which  the  procedure  objects  represent 
the  actions  that  can  be  performed  upon  the  data  objects. 

Each  of  these  forms  of  operating  systems  Is  discussed  next. 

5. 7.1.1  Constituent  Operating  Systems  (COS) 

a.  A  local  computer  system's  own  operating  system;  from  computer  to 
computer  vendor,  each  would  be  heterogeneous  In  characteristics. 

b.  COS  Is  the  set  of  services/functions,  generally  software 
Implemented,  which  manage  the  physical  and  logical  system  resources. 

c.  Serves  as  a  medium  level  Interface  between  users  (people)  and  the 
computer's  physical  machine  resources. 

d.  Provides  services  to  users: 

Process  execution  control,  file  manipulation,  device  manipulation. 
Input/output  control,  system  monitoring/control. 
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c.  User  services  provided  directly  to  processes  and  Indirectly  via 
system  utility  programs. 

f.  Resource  Managers  are  programs  of  the  COS  which  Implement  the  basic 
policies  ever  a  particular  class  of  resources  (l.e. ,  CPU,  memory, 
I/O  devices,  files,  conmunl cation  links). 

g.  Resource  (device)  drivers  are  physical  external  resources  (e.g. , 
printer).  They  are  managed  by  special  purpose  logical  functions 
called  drivers. 

5.7.1. 2  Network  Operating  System  (NOS)  [27] 

a.  Collection  of  software  services/functions  and  associated  protocols 
added  to  heterogeneous  constituent  operating  systems  which  yield  a 
network-wide  set  of  utility  services. 

b.  Implemented  on  collection  of  larc,e  geographic  network  of  computers. 

c.  Provides  uniform,  transparent  access  to  abstract  objects  and 
resources  distributed  around  the  network. 

d.  Objects  and  resources  Interact  using  message  passing  Interprocess 
communications  transactions,  loosely  coupled. 

e.  Location  of  objects  and  resources  are  transparent  to  users. 

f.  Components  Implemented  as  ordinary  applications  software  code  on 
Local  (Constituent)  Operating  Systems. 

g.  Interprocess  connunlcatlcns  employ  virtual  circuits  (long  message 
streams)  and  datagrams  (short,  interactive  transaction  messages). 

h.  Provides  user  access  to  computational  services  to  run  programs, 
manipulate  files.  Input/output  data,  etc. 

1.  Object/resource  managers  utilize  services  provided  by  local 
operating  system,  cooperative  peer  protocols  among  managers  and 
access  networking  utilities  to  use  remote  system  resources. 

j.  Objects  and  object  managers: 

Files,  processes,  devices,  user  ID's,  01  rectory /catalog,  etc. 

5. 7. 1.3  Distributed  Operating  System  (DOS)  [27] 

a.  Collection  of  new,  homogeneous  software  and  protocols  which  replace 
previous  local  operating  sytems  and  provide  global  resource  access, 
allocation  and  management  for  users. 
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b.  Generally  employed  with  localized  networks  of  minicomputers  and 
microcomputers. 

c.  Two  models  generally  used  for  a  DOS: 

Process  model  and  object  model 

d.  Process  mooel  DOS 

•  Each  resource  Is  managed  »y  some  process. 

•  The  operating  system  manages  Interprocess  connunlcatlons. 

e.  Object  model  DOS 

•  Resources  consist  of  objects,  which  have  a  type  and  a  set  of 
operations. 

•  A  capability  must  be  possessed  by  a  user  process  In  order  to 
carry  out  an  operation  on  an  object. 

e  Operating  system  mcnages  the  capabilities  and  to  allow 
operations  to  be  carried  out. 

•  Interprocess  communications  mechanism  employs  either  function 
(or  procedure)  call  or  message  passing. 

5.8  National  Software  Works  (NSW)  Network  Operating  System 

The  NSW  was  reviewed  [28].  It  represents  a  good  example  of  a  Network 
Operating  System  (NOS)  as  Implemented  on  the  ARPANET  Wide-Area  Network.  The  NSW 
provides  a  network-wide  set  of  utility  services  to  users.  The  users  gain  uniform 
access  to  NSW  managed  objects;  such  as  data,  files,  programs  and  computing 
services,  that  are  distributed  around  the  network  on  heterogeneous  machines. 

The  NSW  project  applied  computer  networking  technology  to  Improve  the 
distribution  of  software  tools  and  reusable  software  modules  throughout  the  DOD. 
It  developed  resource  management  techniques  for  a  large  network  of  mixed-vendor 
and  geographically  distributed  computers.  NSW  was  one  of  the  earliest  and  most 
ambitious  attempts  at  building  a  NOS. 

NSW  system  components  (see  Figure  5.8)  consist  of  the  following: 

a.  Front  End  process  (user  Interface)  provides  a  command  language 
Interpreter 

b.  Works  Manager  (NSW  resource  manager  and  access  control  module) 

c.  System  Oata  Base  (NSW  file  system  catalog,  tool  descriptor,  user 
authentication,  user  rights  and  privileges) 

d.  File  Package  Processes  (responsible  for  file  movement  and 
translation) 

e.  Tool  Bearing  Host  Foreman  (The  tool's  Interface  to  NSW) 
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Figure  5.8.  National  Software  Worker  (NSW)  Form  of  Network  Operating  Systems 
f.  Interprocess  Conmunlcations  (message  passing  mechanism  between  NSW 
components ) 

NSW  system  Implementation  Is  functionally  decomposed  Into  units,  as 


follows: 


t  Works  Manager 

•  Front  End 


•  Foreman 


•  File  Package 

N~  components  Interact  cooperatively  via  message-based  Interprocess 
communications  along  well-defined  patterns  known  as  NSW  System  Protocols.  The 
location  of  NSW  cooperating  components  relative  to  each  other  Is  completely 
transparent.  Component-to-component  Interactions  are  grouped  together  Into 
patterns  called  "Scenarios."  An  NSW  scenario  consists  of  the  NSW  process 
Interactions  required  to  implement  a  system  operation,  such  as  starting  a  NSW  tool 
or  copying  a  NSW  File.  NSW  components  are  Implemented  as  ordinary  application 
code  on  local  hosts,  whose  operating  system  treats  it  as  any  entity  making 
resource  demands  on  the  system.  NSW  system  Implementation  therefore  occurs  by  the 
programmed  cooperation  among  otherwise  Independent  elements  with  each  local  host 
operating  system  unaware  of  the  NSW.  MSW's  Network  Operating  System  consists  of 
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so.^+ware  that  was  added  to  the  original  host  computer  Constituent  Operating 
Systems.  The  NSW  managed  resources  are  treated  as  objects.  The  objects  are  the 
elements  making  up  the  NSW  resource  space,  such  as  files  and  services. 

NSW's  resource  space  Is  defined  by  the  resource  catalog.  The  resource 
catalog  and  NSW  software  using  It  Implement  a  global  symbolic  name  space  for 
objects.  An  object's  name  Is  like  the  path  through  the  hlerarchal  NSW  name  space. 
Access  control  Is  based  on  permissions  held  by  the  accessing  agent  referred  to  as 
keys.  Three  kinds  of  permissions  are  defined  for  reading  and  writing  the  catalog: 

•  Lookup  (Oeject  lookup) 

e  Enter  (Object  name  creation) 

•  Delete  (Object  name  removal) 

Other  types  of  permissions  are  applicable  to  more  object  types  (e.g. , 
Execute,  applicable  to  service  objects.  NSW  provides  public  keys;  these  are 
available  to  all  users.  In  addition,  there  are  object  attributes: 

•  Type  -  Name  of  system  supported  types  (e.g..  File) 

•  Site  -  Host  on  which  the  objects  reside 

The  following  summarizes  the  main  characteristics  of  the  NSW  File  Systems: 

a.  Files  are  the  dominant  objects  populating  the  resource  catalogs  and 
are  key  Items  In  the  Interoperability  of  NSW  program  services. 

b.  Two  forms  of  storage  systems  for  NSW  users  and  services 

-  Long-term,  sharable  uniform  space  for  files 

-  Workspace  support  Is  short-term  and  private 

c.  File  presentation 

-  Data  types  (text,  binary) 

-  File  structure  types  (sequential,  record) 

d.  File  Translations 

-  Text  to  text 

Text  to  formatted  text 

Sequential  text  to  record  structured  text 

Record  text  to  sequential  text 

Record  binary  to  sequential  Binary 

e.  File  Transfers 

Moved  from  sost  to  host  using  connection-oriented  Interprocess 
communications 
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NSW  Program  Services  provides  users  access  to  computlonal  services  on 
tool  bearing  hosts.  Services  are  a  type  of  object  managed  by  the  system.  Users 
provided  a  uniform  Interface  for  Invoking  any  service  by  Its  resource  catalog  name 
(a  service  spec).  NSW  services  supported  are: 

a.  Single  Interactive  programs  (user  is  logged  Into  host) 

b.  Service  bearing  host  NSW  command  interpreters  (for  manipulating  NSW 
files  and  to  run  services  on  host) 

c.  Service  bearing  host  native  command  Interpreters  (for  Interacting 
with  standard  native  command  language)  to  manipulate  files  and  run 
programs 

d.  Service  bearing  host  operating  system  (Initial  connection  to  host) 

e.  Batch  services  (submits,  runs  NSW  jobs,  executes  and  returns 
resul ts) 

Users  Interface  to  NSW  via  The  Front  End.  Front  end  functions  include: 

a.  Command  Interpretation  support 

b.  Interaction  with  NSW  system  components  (to  run  services,  manipulate 
files,  etc.)  (and  status  gathering  on  NSN  components  and  data 
bases)  by  way  of  various  pro tool  scenarios 

A  communication  path  employs  a  Telnet  connection  between  the  user's 
front  end  and  a  service.  Terminal  control  Is  as  follows: 

a.  User  employs  a  terminal  to  Interact  with  front  end 

b.  User  employs  a  Telnet  connection  to  conmunlcate  with  a  local  remote 
front  end. 

NSW  Interprocess  Communications  was  found  to  have  the  following 
characteristics: 

a.  Front-End  to/from  Works  Manager  (short.  Infrequent  among  unrelated 
processes) 

•  User  requests  for  NSW  resources  and  responses 

•  Consists  of  short  messages  of  approximately  1000  bits  to  and 
from  work  manager 

•  Transaction  processed  by  any  on  several  works  managers 

t  Short  request,  brief  delay,  short  response,  a  long  delay  until 
the  next  element 

b.  Tool/Foreman  to/from  Works  Manager  (short.  Infrequent  among 
unrelated  processes) 

•  Same  characteristics  as  above,  except  these  are  more  frequent 
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c.  Front-End  to/from  Tool /Foreman  {more  frequent,  short,  continuing, 

among  related  processes) 

•  Consists  of  user  commands  to  tools  and  tool  responses  to  users 

•  Some  patterns  are  same  as  above 

•  Often  patterns  differ:  Consecutive  requests  are  related  and 
must  be  serviced  by  the  same  tool 

•  Varies  from  the  Infrequent,  short  request  pattern  to  frequent, 
long  transmissions 

d.  File  package  to/from  File  package  (Infrequent,  very  long,  among 

related  processes) 

•  Small  fraction  are  short.  Infrequent  messages 

•  Bulk  Is  files  (Infrequent  transmission  of  many  bits) 

5.9  The  Cronus  Distributed  Operating  System 

5.9.1  Introduction 

The  Cronus  DOS  was  one  of  several  models  for  the  LAN  study,  upon  which 
the  Identification  of  networking  protocols  was  made.  Cronus  represents  an 
advanced  development  which  will  structurlze  a  new  architecture  and  establish  the 
requirements  for  interprocess  communications.  The  Cronus  tOS  plans  to  employ  the 
DOD's  Transmission  Control  Protocol  (TCP)  and  Internet  Protocol  (IP)  along  with  a 
high-speed  data  bus  LAN.  The  following  describes  the  Cronus  DOS  and  the 
Interprocess  Comunicatlons  architecture,  based  on  references  [29,  30  and  J], 
Cronus  imposes  global  resource  management.  Including  fault  tolerance,  and  Is 
designed  on  an  object-oriented  model. 

5.9.2  Cronus,  A  Distributed  Operating  System 

Distributed  systems  can  be  classified  along  architectural  lines 
according  to  the  physical  extent  of  distribution  the  system  exhibits.  We  can 
identify  three  major  architectural  areas  of  interest: 

1.  Node  Architecture  (Local) 

2.  Cluster  Architecture  (Regional) 

3.  Inter-Cluster  Architecture  (Global) 

Each  of  these  is  related  to  the  emergence  in  technology  of  distributed 
systems,  but  the  technology  of  distribution  tends  to  be  different  In  the  three 
areas,  ?s  explained  below. 
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5.9. 2.1  Node  Architecture 

The  development  of  a  processor  architecture,  configuration,  and 
operating  system  for  a  single  host  or  processing  node  Is  a  large-scale 
undertaking,  usually  accomplished  by  computer  manufacturers.  A  host  Is  typically 
pnyslcally  small  (can  be  contained  In  one  room).  Is  designed  by  computer  hardware 
architects  as  a  single  logical  unit,  and  Is  concerned  with  maximum  event  rates  of 
approximately  1  to  1000  million  events  per  second.  Although  dual -processor  nodes 
nave  been  common  for  some  time,  nodes  with  mary-fold  Internal  distribution  are 
just  now  becoming  commercially  available.  The  structure  and  efficient  utilization 
of  such  hosts  are  at  the  forefront  of  computer  architecture  research. 

5. 9. 2.2  Cluster  Architecture 

A  cluster  Is  a  collection  of  nodes  (Figure  5.9. 2. 2)  attached  to  a 
high-speed  local  network.  At  present,  technology  limits  the  speed  of  local 
networks  to  approximately  10  to  100  megabits  aggregate  throughput,  and  the 
physical  size  of  the  network  to  a  maximum  diameter  of  about  4  kilometers.  The 
host  systems  are  made  to  work  together  through  the  agency  of  the  distributed 
operating  system,  which  provides  unifying  services  and  concepts  which  are  utilized 
by  application  software.  The  maximum  event  rate  at  the  DOS  level  Is  related  to 
the  minimum  message  transmission  time  between  hosts,  and  is  on  the  order  of  10  to 
1000  messages  per  seconds.  The  cluster  configuration  and  applications  supported 
by  It  are  typically  under  the  admlnl strati ve  control  of  one  organizational  entity. 

5.9. 2. 3  Inter-Cluster  Architecture 

An  inter-cluster  architecture  (Figure  5. 9. 2. 3)  typically  deals  with 
geographically  distributed  clusters  (or  In  the  degenerate  case,  hosts)  which  are 
not  under  unified  administrative  control.  Because  of  administrative  issues  and 
the  greater  lifespan  of  Inter-cluster  architectures,  they  tend  to  be  composed  of 
parts  from  many  different  hardware  and  software  technologies.  The  coimunl cation 
paths  between  widely  separated  clusters  have  much  lower  bandwidth  and  higher  error 
rates  than  local  networks;  the  maximum  event  rate  for  cluster-to-cluster 
Interactions  Is  on  the  order  of  0.01  to  10  events  per  second.  In  the 
inter-cluster  case,  emphasis  Is  on  defining  protocols  for.  Interactions  between 
clusters  and  on  the  appropriate  rules  for  the  exchange  of  authority  (for  access  to 
information  and  consumption  of  resources)  between  clusters. 

5.9.3  The  Cronus  DOS  Functions 

Expected  usage  of  the  DOS  can  be  divided  Into  five  categories: 

1.  Applications 

2.  Application  development  and  maintenance 
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Figure  5. 9. 2. 2.  The  Local  Cronus  Cluster  Configuration  (Physical  Model) 

3.  System  administration 

4.  System  operation 

5.  System  development  and  maintenance 

The  system  Is  Intended  primarily  to  support  end  application  usage. 
However,  to  adequately  support  end  applications  It  must  also  support  the  other 
categories  of  use. 

The  DOS  system  will  provide  functions  in  the  following  areas: 

•  System  Access.  The  objective  Is  to  support  flexible,  convenient 
access  to  the  system  from  a  variety  of  user  access  points. 

t  Object  Management.  The  notion  of  a  "DOS  object"  is  central  to  the 
user  model  for  the  DOS.  The  DOS  treats  resources,  such  as  files, 
programs  and  devices,  as  "objects"  which  It  manages,  and  which 
users  and  application  programs  may  access.  The  objective  of  the 
object  management  mechanisms  Is  to  provide  users  and  application 
program  uniform  means  for  accessing  DOS  objects. 
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Figure  5.9. 2. 3.  The  Cronus  Inter-Cluster  Environment  (Physical  Model) 

•  Process  Management.  The  "process"  abstraction,  also  a  Cronus 
object.  Is  central  to  the  user  model  of  the  DOS.  In  addition.  It 
Is  useful  as  an  organizing  paradigm  for  the  Internal  structure  of 
the  OOS.  The  objective  of  the  DOS  process  management  mechanisms  Is 
to  Implement  the  "process"  notion  In  a  way  that  enables  processes 
to  be  used  both  to  support  the  execution  of  application  programs 
for  users  and  Internally  to  Implement  OOS  functions. 

•  Authentication,  Access  Control,  Protection,  and  Security.  The 
objective  Is  to  provide  controlled  access  to  the  DOS  objects. 

•  Symbolic  Naming.  DOS  users  will  generally  reference  objects  and 
services  symbolically.  Symbolic  access  to  DOS  objects  will  be 
supported  by  means  of  a  global  symbolic  name  space  for  objects. 
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•  Interprocess  Communication.  The  objective  of  the  Interprocess 
communication  (IPC)  facility  Is  to  support  communication  among 
processes  Internal  to  the  DOS,  and  among  user  and  application  level 
processes. 

§  User  Interface.  The  user  Interface  functions  provide  human  users 
with  uniform,  convenient  access  to  the  features  and  services 
supported  by  the  DOS  resources. 

a  Input  and  Output.  The  objective  here  Is  to  provide  flexible  and 
convenient  means  for  users  and  programs  that  act  of  the  behalf  of 
users  to  make  use  of  devices  such  as  printers,  tape  drives,  etc. 

•  System  Monitoring  and  Control.  The  purpose  of  the  system 
monitoring  and  control  functions  is  to  provide  a  uniform  basis  for 
operating  and  manually  controlling  the  system. 

The  principal  goal  for  the  DOS  In  each  of  these  functional  areas  Is  to 
support  features  that  are  comparable  to  those  found  In  modern,  conventional, 
centralized  operating  systems. 

5.9.4  DOS  Provides  Essential  Services  System-Wide 

At  the  heart  of  the  DOS  concept  is  the  availability  of  selected,  essential 
services  to  all  of  the  applications  In  the  DOS.  The  coherence  and  uniformity  of 
the  DOS  Is  directly  enhanced  when  applications  and  application  host  operating 
systems  embrace  the  DOS-supplied  services  as  the  single  source  of  these  services. 

To  the  extent  that  applications. and  application  host  operating  systems  choose  to 
utilize  parallel  but  Incompatible  services,  coherence  and  uniformity  Is  lost. 

At  this  time  the  essential  services  are: 

•  User  access  points  (terminal  ports,  workstations)  providing  a 
uniform  path  to  all  DOS  services  and  applications 

•  Object  management  (cataloging  and  object  manipulation)  for  many 
types  of  00S  objects 

•  Uniform  facilities  for  process  Invocation,  control,  ar.d 
interprocess  communication  for  application  builders 

•  Cluster-wide  user  Identifiers  and  user  authentication  as  the  basis 
for  uniform  access  control  to  DOS  resources 

•  Cluster-wide  symbolic  name  space  for  all  types  of  DOS  objects 

•  A  standard  Interprocess  communication  (IPC)  facility  supporting 
datagrams  and  virtual  circuits 

•  A  well -designed  user  Interface  that  provides  access  to  all  DOS  and 
applications  services 
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i  Input/output  services  for  the  exchange  of  data  with  people  and 
systems  apart  from  the  DOS 
e  Host  monitoring  and  control  services,  and  additional  mechanisms 
needed  for  cluster  operation 
5.9.5  Cronus  Logical  Model  Architecture 

While  Cronus  can  be  described  In  Its  physical  sense,  this  will  discuss 
the  LAN  Study's  logical  view  of  the  Cronus  architecture.  Figure  5. 9.5-1 
Illustrates  a  view  of  the  Cronus  DOS  architecture,  structured  In  a  top-down  view, 
starting  at  the  top  with  the  user.  Some  functions  at  the  bottom  would  be 
Implemented  and  be  under  the  control  of  a  Constituent  Operating  System  (COS). 
Those  above  this  level  would  be  Implemented  on  the  COS  but  would  be  under  the 
control  of  the  global  operating  system. 
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Figure  5. 9. 5-1.  CRONUS  DOS  Architecture  (Logical  View) 

In  regard  to  the  Cronus  global  operating  system,  It  was  concluded  by 
the  LAN  Study  Team  that  In  spite  of  It  being  called  a  Distributed  Operating  System 
(DOS),  the  makeup  and  architecture  Is  that  of  a  Network  Operating  System  (NOS), 
meeting  the  criteria  given  by  reference  [27], 
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Cronus  Is  an  object-based  architecture.  Objects  can  be  physical  or 
logical.  Objects  have  object  managers.  The  Cronus  objects  and  their  Managers  can 
be  dispersed  throughout  a  distributed  system  environment.  This  Is  show  by  Figure 
5. 9.5-2.  It  shows  two  machines  on  two  different  clusters.  Interconnected  by  an 
Internet  with  gateways. 


Figure  5. 9. 5-2.  Distributed  System  Environment 
Users  and  objects  (devices)  Interface  to  their  respective  object 
managers.  They  In  turn  communicate  with  other  object  managers  by  exchanging  data 
plus  control  messages.  These  exchanges  follow  well-established  rules,  called 
protocols.  A  family,  or  suite,  of  peer  protocols  are  needed  In  order  for  the 
Cronus  type  of  resource  distribution  to  properly  Interoperate.  Figure  5. 9. 5-2 
Identifies  where  the  LAN  Study  Team  views  networking  protocols  to  reside  1r. 

Cronus.  The  layers  5-7  set  of  high  layer  protocols  Interface  and  provide  services 
to  the  distributed  object  managers.  The  high  layer  protocols  correspond  to  the 
application,  presentation  and  session  layers  of  the  OSI/RM  and  use  the  underlying 
Layer  4-Media  Interprocess  Communications  facility  for  exchanging  Object  Manager 
pear  protocol  messages.  There  are  tiers  of  peer  protocols  considered  needed  for 
use  between  the  distributed  object  or  resource  manager  type  entitles. 
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5.9.6  Ci^onus  Cluster  Physical  Model 

The  equipment  configuration  shown  In  Figure  5. 9.2.2  for  the  DOS  cluster 
Is  briefly  reviewed.  The  OOS  cluster  Is  composed  of  three  types  of  equipment: 

1.  Application  Hosts.  These  may  be  general-purpose  hosts  (e.g., 
timesharing  machines)  providing  services  to  many  DOS  users,  or 
workstations  providing  services  to  one  user  at  a  time,  or 
special-purpose  hosts  (e.g.,  signal  n.-ccesslng  computers)  required 
by  just  one  DOS  application.  Application  hosts  are  often  user 
programmable.  In  general,  they  have  many  characteristics  which  are 
not  under  the  control  of  the  OOS;  the  DOS  must  be  sufficiently 
flexible  to  Incorporate  application  hosts  of  almost  any  kind. 

2.  DOS  Service  Hosts.  These  machines  are  dedicated  entirely  to  DOS 
functions  and  exist  only  to  provide  services  to  DOS  users  and 
applications.  In  general,  they  represent  modules  with  specific, 
system-oriented  functions  (e.g.,  archival  file  storage)  and  are  not 
user  programmable.  Requirements  for  the  DOS  service  host  types  and 
operating  systems  will  be  specified  In  the  DOS  design  documents. 

3.  A  Communication  Subsystem.  The  subsystem  consists  of  a  high 
bandwidth,  low-latency  local  network,  hardware  Interfaces  between 
hosts  and  the  local  network,  device  driver  software  In  the  host 
operating  systems,  and  low-level  protocol  software  (the  data  link 
layer)  In  the  hosts. 

Application  hosts  will  be  connected  to  the  communl cation  subsystem  In 
one  of  two  ways:  1)  directly,  by  means  of  a  ho st-to-1  oca 1 -network  device 
Interface;  or  2)  Indirectly,  through  an  Intermediary  DOS  service  host  called  an 
access  machine. 

5.9.7  DOS  Generic  Computer  Elements 

The  concept  of  a  Generic  Computing  Element  (GCE)  Is  Important  to  the 
DOS  design.  A  GCE  Is  an  Inexpensive  DOS  host  that  can  be  flexibly  configured  with 
small  or  large  memory,  and  with  or  without  disks  and  other  peripherals,  as  shown 
In  Figure  5.9. 2. 2.  GCE's  will  be  configured  for,  and  dedicated  to,  specific  DOS 
service  roles,  such  as  terminal  multiplexing,  file  storage,  access  machines,  and 
OOS  catalog  maintenance. 

The  GCE's  are  the  basis  for  Implementing  the  essential  DOS  services  In 
a  uniform,  application-host-independent  manner.  Because  the  DOS  design  will 
specify  the  properties  of  GCE's  and  also  the  software  components  running  on  them. 


1761DAAN 


5-62 


It  Is  possible  to  control  the  performance  and  reliability  characteristics  of  the 
essential  DOS  services.  A  configuration  consisting  of  the  local  network,  some 
number  of  GCE*s  and  supporting  the  essential  services  represents  the  minimum 
useful  00$  Instance. 

Application  programs  can  be  constructed  above  the  GCE  hardware  and 
operating  system;  a  single  GCE  host  may  support  DOS  services  or  user  applications, 
but  not  both. 

5.9.8  Interprocess  Communication  (IPC) 

The  objective  of  the  DOS  Interprocess  communication  (IPC)  facility  Is 
to  support  the  communication  requirements  of  the  DOS.  The  Cronus  IPC  is  shown  In 
Figure  5.9.8.  Requirements  can  be  Identified  at  two  levels; 

CRONUS  INTERPROCESS  C0MMUNICAT10S  (IPC) 


HIP  =  HIGH  LEVEL  PROTOCOL  =  OBJECT  OPERATION  PROTOCOL  (OOP) 

OOP  =  USED  TO  PASS  HIGH  LEVEL  PROTOCOL  MESSAGES  AMONG  PROCESS  TO  PROCESS.  PROCESS  TO  MANAGER  ANO 
MANAGER  TO  MANAGER 

THE  MESSAGE  STRUCTURE  LIBRARY  (MSL)  PROVIOES  ROUTINES  FOR  THE  COMPOSITION  ANO  EXAMINATION  OF 
HIGH  LEVEL  IPC  PROTOCOL  MESSAGES 

OOP 

MESSAGE 

TYPES  =  REQUEST.  REPLY  ANO  IN  PROGRESS 

MSL  =  MESSAGE  STRUCTURE  LIBRARY  (APPLICATION  INTERFACE  FUNCTIONS.  OATA  TRANSLATION  FUNCTIONS.  AND 
STRUCTURE  MANIPULATION  FUNCTIONS)  (APPEARS  TO  3E  OSI  LAYERS  7.I.S  SERVICES) 
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Figure  5.9.8.  Cronus  Interprocess  Communication 
1.  The  System  Implementation  Level.  The  collection  of  software 
modules  that  Implement  the  DOS.  The  DOS  executes  as  processes  on 
various  DOS  hosts.  These  Interactions  are  supported  by  the 
Interprocess  communication  facility. 
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!.  The  User  Application  Level.  Some  of  the  application  programs  that 
execute  In  the  DOS  environment  may  be  structured  as  distributed 
programs.  A  distributed  program  is  one  whose  components  may  run  as 
cooperating  processes  n  different  hosts.  The  components  of  such  a 
distributed  application  program  will  need  to  communicate. 

The  IPC  facilities  that  are  available  at  the  application  level  will  be 
built  upon  the  system  level  IPC  facility. 

The  OOS  Interprocess  communication  (IPC)  facility  will  be  based  on  the 
following  principles: 

e  Tne  IPC  mechanism  will  support  a  variety  of  communication  modes 
Including  datagrams  ar.d  connections  (l.e.,  reliable  sequenced,  flow 
controlled  data  streams). 

•  It  will  be  built  upon  the  standard  000  IP  (Internet)  and  TCP 
(transmission  control)  protocols.  This  assumes  that  the 
Implementations  of  the  00D  protocols  that  are  used  will  provide 
adequate  performance  (low  delay,  high  throughput).  If  they  do  not. 
It  may  be  necessary  to  build  the  IPC  directly  on  the  local  network 
(Ethernet)  protocol. 

•  Interhost  and  Intrahost  communication  will  be  treated  In  a  uniform 
fashion  at  the  interface  to  the  IPC  facility.  That  Is,  the  same 
IPC  operations  used  for  communicating  with  processes  on  different 
hosts  will  be  used  for  communicating  with  ones  on  the  same  host. 

Of  course,  to  achieve  the  efficiencies  that  are  possible  for  local 
communication,  the  IPC  Implementation  will  treat  Interhost 
communication  differently  from  local  communication. 

•  Several  levels  of  addressing  will  be  supported  by  the  IPC 
facility.  The  details  of  IPC  addressing  within  the  DOS  have  not 
yet  been  finalized.  The  fundamental  Issue  which  Is  unresolved  Is 
what  the  addressable  entity  for  the  IPC  facility  shall  be;  that  Is, 
to  what  will  datagrams  be  addressed  and  what  will  connections 
connect?  One  reasonable  choice  would  be  for  the  process  Itself  to 
be  the  addressable  entity.  Alternatively,  another  abstraction,  the 
"port,"  could  be  Introduced  for  this  purpose.  Ports  would  be 
objects,  and  like  other  objects  such  as  processes,  they  would  have 
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unique  ID's  and.  If  cataloged,  could  be  referenced  symbolically  by 
name.  Regardless  of  the  choice  for  addressable  entity,  the  IPC 
facility  will  permit  addressing  by  means  of  unique  ID  and  by 
means-of  symbolic  name.  Other  levels  of  addressing  may  also  bo 
supported.  At  the  interface  to  the  IPC  facility  wherever  IPC 
address  is  expected,  any  of  the  supported  levels  of  addressing 
(unique  ID,  symbolic  name)  may  be  used. 

•  The  ability  of  the  IPC  facility  to  deal  with  symbolic  addresses 
will  permit  It  to  support  "generic-  addressing.  This  will  permit 
processes  to  specify  Interactions  with  other  processes  in 
functional  terms. 

•  The  IPC  mechanism  will  provide  means  to  directly  utilize  some  of 
the  capabilities  of  the  local  network.  For  example,  the  Ethernet 
supports  efficient  broadcast  and  multicast.  The  IPC  will  provide 
relatively  direct  access  to  these  capabilities  by  supporting 
broadcast  and  multicast  addressing.  To  achieve  the  design  goal  of 
component  substitution  it  Is  Important  for  the  DOS  system  to  be  as 
Independent  as  possible  of  the  specific  characteristics  of  the 
particular  local  network  chosen  for  the  ADM.  Therefore,  care  must 
be  taken  to  avoid  building  dependencies  on  the  particular  ADM 
network  technology  Into  lower  level  DOS  mechanisms,  such  as  the 
IPC.  If  such  dependencies  cannot  be  avoided,  care  must  be  taken  to 
minimize  their  Impact  on  the  DCS.  In  our  opinion,  this  Is  not  an 
Issue  In  the  case  of  the  broadcast  and  multicast  facilities,  since 
many  state  of  the  art  local  network  technologies  support  similar 
capabilities. 

5.9.9  The  Communication  Subsystem 

A  high-bandwidth,  low-latency  local  network  Is  the  backbone  of  the 
DOS.  The  DOS  concept  of  operation  will  specify  the  Interface  to  the  local 
network,  so  that  alternate  local  network  technologies  can  be  substituted  for  the 
particular  local  network  chosen  for  the  Advanced  Development  Model. 

The  local  network  will  permit  every  host  to  communicate  with  every 
other  host  In  the  DOS  cluster  and  will  provide  an  efficient  broadcast  service 
from  any  host  to  all  nosts.  The  local  network  Interface  specification  may  further 
restrict  the  minimum  packet  size,  addressing  mechanism,  and  other  local  network 
properties. 
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5.9.10 


Candidate  Protocols  for  Cronus 

The  Cronus  DOS  design  employs  several  protocols.  Some,  like  the 
underlying  Ethernet  and  Transmission  Control  and  Internet  Protocols  (TCP/IP) ,  are 
Industry  and  000  standard  forms.  These  provide  the  basic  Interprocess 
communications.  Others,  like  the  MSF,  SER,  MSI,  OS,  and  OOP,  are  new  ones 
developed  for  Cronus.  These  perform  higher  layer  type  protocol  functions.  They 
correspond  to  the  OSI/RM  layers  5,  6,  and  7  In  the  following  ways: 

a.  Control  and  Stream  message-based  protocols 

b.  Cronus  Message  Structure  Facility  (KSF)  consisting  of  a  Message 

Structure  Library  (MSL)  and  a  Standard  External  Representation  (SER) 

-  The  MSL  seems  to  be  the  same  services/functions  which  OSI 
Presentation  Layer  Is  to  perform. 

-  The  SER  deals  with  data  structuring,  also  part  of  OSI 
Presentation  Layer. 

c.  Operation  Switch  (OS) 

-  The  OS  functions  dealing  with  asynchrony  and  demultiplexing 
correspond  to  the  OSI  Session  Layer. 

d.  Object  Operation  Protocol  (OOP) 

-  The  OOP  appears  to  correspond  with  some  of  the  OSI  Application 
Layer  protocols  for  object-based  distributed  processing 

Close  coordination  between  Cronus  and  OSI  protocols  might  permit 
employment  In  the  future  of  higher  layer  Industry  protocols  as  that  work  matures 
and  could  be  fitted  Into  and  upgraded  or  productized  form  of  Cronus.  The 
following  subsection  discusses  a  Generic  network  Operating  System,  called  GNOS, 
wnlch  Is  an  approach  to  avoiding  the  probable  heterogeneity  the  current  Cronus 
exhibits. 

5.10  Generic  Network  Operating  System  (GNOS) 

5.10.1  Introduction 

To  avoid  the  development  of  a  closed  or  heterogeneous  global  operating 
system  set  of  networking  protocols,  a  general  representation  of  a  Network 
Operating  System,  called  GNOS,  was  developed.  With  the  emerging  International  OSI 
attempt  to  build  a  family  of  open  system  Interconnection  protocols  to  create  a 
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global  open  networking  system,  the  LAH  Study  Team  took  the  view  that  a  generic, 
rather  than  a  possible  proprietary  form  such  as  the  Cronus  global  operating 
system,  formed  e  better  base  to  construct  command,  control  and  comnuinl cations 
protocols  upon.  This  subsection  discusses  GNOS,  Its  architecture,  subsystems, 
services,  functions  and  protocols. 

5.10.2  Objectives  for  GNOS 

The  following  Is  a  statement  of  objectives  and  purpose  for  GNOS: 
Objectives 

To  describe  a  generic  visualization  of  a  distributed  processing 
Network  Operation  System  (NOS)  which  exhibits  tne  capabilities  to 
manage  the  resources  of  a  collection  of  connected  computers, 
peripherals,  Input/output  devices  and  a  means  for  Interprocess 
communications.  GNOS  defines  the  functions  and  Interfaces 
available  to  application  programs  on  system  hosts. 

GNOS  specification  provides  an  open*  reference  model  to  focus 
protocol  standardization,  study  and  development  works  upon. 

GNOS  provides  the  Air  Force  a  reference  model  to  guide  development 

3 

of  C  technology,  protocols  and  systems. 

Purpose 

-  Provide  a  unified  representation  nf  an  Integrated  distributed 
processing  network  operating  system  In  terras  of  its  arcnltecture, 
subsystems,  services,  functions  and  protocols. 

5.10.3  GNOS  Architecture 

The  GNOS  Architecture  consists  of  the  following  principles  and  Is 
Illustrated  by  Figure  5.10.3: 

Object  oriented  abstract  design. 

System  consists  of  a  collection  of  objects  that  are  accessed  or 
updated  by  users  tnrough  transactions. 

-  Users  access  applications  programs,  wnlch  access  object  (resource) 
managers.  These  access  local  resources  by  way  of  a  Constituent 
Operating  System  or  remote  resources  by  way  of  networking  utilities 
protocols  and  Interprocess  communications  protocols.  Presentations 
Layer  provides  unifying  Information  representation  and  interface 
for  the  resource  managers  to  the  Interprocess  conmunl cations  and 
data  storage/retrieval  subsystems. 


*Upen  means  It  Is  vendor  independent. 
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Figure  5.10.3.  Generic  Network  Operating  System  (GNOS) 

»  Parallel  processing  programming  language  exhibiting  strong  data 
typing  Implements  application  programs. 

-  An  “Operating  System  Corniand  and  Response  Language  (OSCRL)" 
provides  a  global  system-wide  command  language  for  users  and 
processes  to  access  sy.tem  resources. 

-  Resource  manager's  protocols  and  networking  utility  protocols  are 
grouped  as  a  unified  subsystem  of  interconnected  Network  Units 
(NU's). 

-  Network  Units  cooperate  by  passing  messages  to  each  other  via 
Interprocess  communications. 

-  The  interprocess  communications  supports  Intra-host  and  lccal/wlde 
area  Inter-host  services  via  a  loosely  coupled  suite  of  message 
passing  networxing  protocols. 

-  Distributable  functions  supported: 

•  Application  programs 

•  Application  subsystems 

•  Processing 
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•  Data  Base 

•  Communication? 

•  End-user  devices 

5.10.4  GNOS  Subsystems 

The  following  subsystems  were  Identified  for  GNOS: 

-  User  terminals  and  terminal  managers. 

-  General  purpose  processors  and  peripherals. 

-  Storage  {short-term,  long-term). 

Interprocess  communications. 

-  Constituent  Operating  System(s) 

-  Network  Operating  System  comprised  of  resource  managers  and 
networking  utilities  grouped  Into  Network  Unit  subsystems  (NU’s). 

-  Application  programs  and  subsystems. 

-  Processing  environment. 

-  File  and  Data  Base. 

5.10.5  GNOS  Services 

The  following  were  Identified  as  services  which  GNOS  provides: 

-  User  access/authentication 

-  Multilevel  security 

-  Object  management 

-  Process  management 

-  Resource  management 

-  Networking  utilities  (remote  access  to  files,  terminals,  jobs, 
messages) 

-  Operating  System  Command  and  Response  Language  (OSCRL) 

-  Task  assignment  arr*  management 

-  Directory  (symbolic  name  to  network  identifier) 

Data  base  management 

-  Input/output 

-  Monitoring  and  control 

-  Supports  transaction  and  job  processing 

-  Program  generation.  Invocation  and  support 

-  Access  local  resources  via  constituent  operating  system  Interface 

-  Resources  managed: 

•  Processor  cycles 

•  Main  storage 
t  Files 
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•  I/O  devices 

e  Sessions,  queues,  data  base  records 

5.10.6  GNOS  Functions 

The  following  GNOS  functions  were  Identified: 

Resource  allocation  and  management  (programs  request  access  to 
resource  via  a  request  to  Its  object  manager.  Higher  functions  may 
come  Into  play  to  recover,  secure,  change  control);  these  functions 
can  be  system-wide,  network  remote  or  local  on  Its  Constituent 
Operating  System. 

Provides  user  interface,  authentication/ access  protection  and 
system  access. 

Common  command  language  interpreter. 

Interprocess  communications  (connection-oriented  for  streams  and 
connection-less  for  transaction  messages). 

-  Process  management,  distributed  task  scheduling,  multitasking  and 
concurrent  processing  performed. 

File  access,  transfer  and  manipulation. 

-  Job  transfer  and  management. 

Distributed  data  base  access,  update  and  management. 

System  monitoring  and  control,  fault  tolerance  and  system  recovery. 
Provide  access  to  local  operating  system  functions. 

-  Directory  namlna/addresslng. 

Capacity  management. 

Configuration  and  reconfiguration  management  of  processors, 
cluster,  global  system. 

Support  information  processing  of  data  (creation,  dlstrloutlon, 
storage,  manipulation,  output). 

Multilevel  security  (authentication,  resource  access,  encryption). 

5.10.7  Protocols  Needed  to  Support  GNOS 

This  subparagraph  discusses  the  protocols  Identified  as  being  required 
to  support  the  GNOS.  Message-based  transaction  and  file  transfer  protocols.  In 
support  of  software  program  functions,  comprise  the  Generic  Network-wide  Operating 
System  (GNOS).  Software  program  functions  perform  distributed  resources  (object) 
management  operations  In  support  of  the  distributed  applications  (policy 
setting/execution  functions  reside  here)  by  way  of  resource  manager  protocols  and 
assessing  networking  utility  services. 
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A  networking  protocol  suite  Is  comprised  of  three  service  regions: 

e  Networkl ng-WI de  Utilities  (Canonical  form  of  high  level  services 
for  accessing  remote  resources) 

•  Host  to  Host/ internet  data  transport  services 

•  Local /Wide  Area  Network  transmission  services 

Networking-wide  Utilities  provide  generic  services  to  the  resource 

(object)  manager  entitles  to  enable  remote  resource  access  to  files,  terminals, 
data,  jobs,  messages,  etc.  The  combination  of  resource  (object)  managers  and 
networking-wide  utilities  functions  comprise  the  distributed  Network  Operating 
System  (NOS);  where  a  local  resource  is  employed,  the  resources  manager  accesses 
It  using  Its  Constituent  Operating  System  (COS). 

Resource  Managers  make  a  set  of  resources  available  to  users 
(programs),  such  as  processor  cycles,  main  storage,  files  on  disk  or  tape,  such 
I/O  devices  as  keyboards  or  displays,  and  such  abstract  resources  as  sessions, 
queues,  or  data  base  records.  Resource  Managers  allocate  resources  to  users  as 
Its  central  function  In  response  to  a  user  request.  This  Includes  access 
scheduling,  coordination,  resource  allocation  deadlock  detection,  resource  change 
commitment  control,  resource  access  security  and  resource  formatting  services. 
Resource  Managers  employ  resource  coordination  peer  protocols  end  access  network 
services  by  way  of  Interfacing  to  the  networking-wide  utility  protocol  services. 

Program  to  Program  protocols  exchanged  between  Resource  Manager /Network 
Utility  entitles  make  up  the  distributed  Network  Operating  System.  Protocols 
support  cooperation  among  the  distributed  resources  managers  to  perform  the 
following  activities: 

•  Interprocess  communications 

•  Data  representation 

•  Data  storage  (media,  file  and  data  base) 

•  Process  management 

•  Resource  management 

a  Integrity  and  security 

•  Program  support 

Protocols  are  needed  at  several  levels  co  enable  distributed  object 
(resource)  managers  to  cooperate  autonomously.  The  levels  Identified  consist  of 
the  following: 

-  User  to  OSCRL 

-  OSCRL  to  Resource  Managers 

Resource  Managers  to  Resource  Managers 
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•  Networking  Utilities  to  Networking  Utilities 

-  Host  to  Host  Interprocess  communications 
e  Transport 

e  Internetwork 

-  Subnet  transmission 

e  Local  area  network 

•  Wide  area  network 

Networking  wide  utility  protocols  required  are*: 
e  Network  management 

e  Virtual  Terminal 

•  File  access,  transfer,  management 

e  Job  transfer/manipulation 

•  Message  handling 

•  Document  Interchange 

a  Name  server 

e  Data  base  access/management 

Gateways  are  required  for  Interoperability 

•  Intra-system  and  Inter system  connectivity  functions  performed 
The  following  protocol  characteristics  were  defined: 

Interprocess  communications  facility  exhibits  a  loosely  coupled 
message  passing  characteristic  (not  memory  sharing).  Transactions 
to  be  the  primary  method  for  objects  to  communicate  through 
exchanging  messages;  however  a  connection-oriented  service  to  be 
required  for  transferring  files. 

Message  exchange  characteristics: 

•  Intra-host  (local  only) 

•  Inter-host  (LAN  only,  LAN/internet/LAN) 

Message  types: 

•  Snail,  minimal  effort  (datagram  service) 

•  Snail,  reliable  (virtual  circuit  service) 

•  Large,  reliable  (virtual  circuit  service) 

Predominant  form  of  messages  exchanged  will  be  for  control.  These 
request  operations  to  be  performed  on  objects  ( local /remote ) ,  with 
replies  generated  by  performed  operations,  plus  exception  notices  and 
messages  to  coordinate  the  distributed  object  managers. 

♦Supported  by  Its  type  presentation  and  session  protocols 
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Standardized  Object  Manager  to  Object  Manager  message  types  and 
structuring  Is  required  of  message  formats  employed. 

Asynchronous  handling  of  simultaneous  process  to  process 
transaction  messages  Is  required 

-  Stream  Interprocess  conwunlcatlons  required  between  cooperating 
processes;  has  a  uni -directional  data  channel  session  type  between 
two  objects;  one  Is  a  data  source,  the  other  a  data  sink;  connects 
processes  with  files,  devices,  and  other  processes. 

-  Object  Manager  to  Object  Manager  communications  employs  a  high  level 
form  of  protocol.  Is  asynchronous  and  Involves  handling  Interleaved 
messages  from  possibly  several  processes.  Messages  are  received, 
requests  are  originated  to  satisfy  the  client  requests,  and  a  reply 
message  sent  to  the  original  message.  In  the  case  of  a  failure,  the 
object  manager  assures  the  client  that  either  all  changes  requested 
will  take  place,  or  none  will  for  the  atomic  transaction  performed. 
The  following  resource  (object)  Managers  require  peer  protocols: 

-  Program 
Terminal  Manager 

Author! zatlon/access  control /security 

-  OSCRL 
Catalog 

-  File 
Device  I/O 

Monitoring  and  control 
Network  Management 

-  Data  base 

-  Directory 

-  Host 

5.11  Comparison  of  POD  and  ISO  Networking  Protocol  Reference  Models 

Both  the  DOD  and  ISO  reference  models  have  significant  Impacts  upon  the 
world  of  networking.  Therefore,  It  Is  Important  to  gain  Insight  -..lto  their 
similarities  and  differences.  This  subsection  provides  the  results  of  examining 
these  Issues.  The  following  paragraphs  provide  expanded  discussions  on  both  of 
these. 
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I 

I 

5.11.1  Layered  Archl tectures 

Before  comparing  the  architectures  of  the  International  Standards 
Organization's  Open  Systems  Interconnect  model  (ISO  OSI)  to  the  Department  of 
Defense's  model  It  may  be  well  to  revisit  the  principles  of  protocol  layering. 

Both  of  the  models  are  based  upon  this  concept. 

A  layered  protocol  architecture  provides  a  hierarchy  of  control  by 
functionally  decomposing  overall  network  conmunl cation  objectives  Into  strata. 

Each  stratum,  or  protocol  layer.  Is  supposed  to  provide  a  particular  set  of 
services.  Starting  at  the  lowest  layer,  the  services  of  each  succeeding  layer  are 
available  to  the  layers  above  and  are  built  upon  the  layers  beneath.  The  lowest 
layers  are  more  physical,  the  upper  ones  are  more  virtual  In  their  makeup. 

The  advantages  of  this  approach  are  that  It  allows  for  local 
optimization  (Important  because  of  the  heterogeneous  nature  of  today's  systems) 
while  preserving  the  ability  to  establish  comnon  conmunl  cations  conventions. 

There  Is  also  the  hope  that  this  layered  approach  will  minimize  the  Impact  of 
technical  evolution  by  allowing  functional  replacement  of  a  layer.  The 
practicality  of  this  latter  point  and.  In  fact.  Its  necessity  can  be  questioned. 

The  functionality  of  a  layer  in  no  way  Implies  an  Implementation 
scheme.  Layered  architecture  ollows  the  protocol  designer  the  freedom  to 
Implement  the  function  according  to  the  particular  environment  and  requirements. 

5.11.1.1  Formal  Versus  Soft  Layering  of  Protocols 

Ever  since  the  archl tectural  design  concept  of  layering  was  Introduced, 
particularly  evident  In  the  network  architectures  of  the  ARPANET,  OSI/RM  and 
proprietary  ones  like  IBM's  SNA,  there  has  been  concern  expressed  over  the  Implied 
complexity  or  overhead  penalties  Incurred.  This  paragraph  discusses  these  Issues 
based  upon  References  5,  10,  14,  19,  20,  25,  40,  42,  43,  44,  60,  82,  and  92. 

Layering  Is  a  design  process  whereby  a  set  of  very  complex  and 
Interrelated  functions  are  grouped  In  a  common  way  to  form  a  set  of  hierarchical 
elements,  called  layers.  This  process  breaks  an  otherwise  complex  problem  Into  an 
ordered  set  of  manageable  pieces.  The  grouping  of  functions  Into  a  layer  Is  done 
In  such  a  way  as  to  find  the  combination  which  produces  the  minimum  set  of 
Interface  operations  necessary  between  two  adjacent  layers.  A  layer  can  also  be 
thought  of  as  a  module. 

Layers  of  equal  functionality  can  be  distributed  across  physical 
machines.  When  this  Is  done  in  a  networking  environment,  the  layers  cooperate 
with  equal,  or  peer,  layers  by  exchanging  data  and  control  information.  This  Is 
done  through  message  exchanges.  These  exchanges  must  follow  a  prescribed  set  of 
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rules  which  are  called  peer  protocols.  The  full  set  of  peer  protocols  comprise 
the  networking  communications  protocols. 

Reference  [42]  discusses  the  advantages  and  disadvantage  of  protocol 
layering  and  presents  the  points  given  In  Table  5.11.1.1.  In  summary,  It  stated, 
"In  general,  the  advantages  are  great,  the  disadvantages  slight." 

5.11.1.1.1  Layering  of  the  OSI/RH 

In  the  OSI/RM  -  Communication  takes  place  between  application  processes 
running  in  distinct  systems  in  which  a  system  Is  considered  to  be  one  or  more 
autonomous  computers  and  their  associated  software,  peripherals,  and  users  that 
are  capable  of  Information  processing  and/or  transfer. 

In  the  OSI/RM  Architecture  -  All  services  provided  to  the  application 
process  users  are  grouped  into  seven  subsystems  of  protocol  layers,  whose  entitles 
are  distributed  among  the  Interconnected  systems  and  which  communicate  by  message 
exchange  among  entities  of  equal  layer  in  the  structure  according  to  formal  rules 
of  communications  called  peer  protocols.  This  layering  technique  Is  similar  to 
the  one  used  In  structured  programming,  where  only  functions  performed  by  a  module 
(and  not  Its  internal  functioning)  are  known  by  Its  users. 

Layer  Services  -  These  are  the  capabilities  which  a  layer  provides  to  a 
user  of  that  layer.  Wltnln  a  layer,  functions  will  be  performed,  some  of  which 
are  not  user  provided  services.  Only  capabilities  seen  by  the  user  are  the 
services. 

A  Service  Specification  -  Represents  a  lower  level  of  abstraction  that 
defines  the  service  provided  by  each  layer.  Tighter  constraints  on  the  protocol 
and  the  Implementation  that  will  satisfy  tne  requirements  are  given.  It  defines 
the  facilities  given  to  the  user  and  an  abstract  Interface  for  each  protocol  layer 
by  specifying  the  primitives  the  user  would  invoke  to  access  the  service. 

Layer  Service  Access  Points  -  Abstract  ports  through  which  users 
request  and  receive  the  services  provided  by  a  particular  layer. 

Layered  functions  -  These  a»e  the  activities  which  are  performed  within 
a  layer.  Functions  are  performed  by  layer  entitles  through  cooperation  with  c-ther 
layer  entitles  distributed  throughout  the  network.  Entitles  of  equal  layer  value 
communicate  by  peer  protocols. 

Protocol  Specifications  -  Represent  the  lowest  level  of  abstraction  In 
the  OSI  standards  scheme.  Each  protocol  specification  defines  precisely  what 
control  Information  is  to  be  sent  and  what  procedures  are  to  be  used  to  interpret 
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Table  5.11.1.1,  Advantages  and  Disadvantages  of  Layering 


Advantages  of  Layered  Architectures: 

1.  Any  given  layer  can  be  modified  or  upgraded  without  affecting  the 
other  layers. 

2.  Modularization  by  means  of  layering  simplifies  the  overall  design. 

3.  Different  layers  can  be  assigned  to  different  standards  committees, 
or  different  design  teams. 

4.  Fundamentally  different  mechanisms  may  be  substituted  without 
affecting  more  than  one  layer  (e.g.,  packet  switching  versus 
leased-line  concentrators). 

5.  Different  machines  may  plug  In  at  different  levels. 

5.  The  relationships  between  the  different  control  functions  can  be 
better  understood  when  they  are  split  1n*o  layers.  This  Is 
especially  true  with  the  control  actions  which  occur  sequentially 
In  time  from  layer  to  layer. 

7.  Common  lower  level  services  may  be  shared  by  different  higher  level 
users. 

8.  Functions,  especially  at  the  lower  layers,  may  be  removed  from 
software  and  built  Into  hardware  or  microcode. 

Disadvantages  of  Layered  Architectures: 

1.  The  total  overhead  is  somewhat  higher. 

2.  The  communicating  machines  may  have  to  use  certain  functions  which 
they  could  do  without. 

3.  To  make  each  layer  usable  by  Itself  there  Is  some  small  duplication 
of  function  between  the  layers. 

4.  As  technology  changes  (e.g.,  as  cryptography  and  compaction  chips 
become  available,  or  these  functions  can  be  built  onto  HDLC  chips) 
the  functions  may  not  be  In  the  most  cost-effective  layer. 

In  general,  the  advantages  are  great,  the  disadvantages  slight. 
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this  control  Information.  The  protocol  specif lea tlons  constrain  Implementations 
sufficiently  to  allow  open  systems  to  communicate  whl*.  still  allowing  differences 
In  Implementation. 

5.11.1.1.2  Layering  In  the  000/RM 

The  ARPANET/ DOD  architecture  and  protocols  suites  for  networking 
predate  the  work  of  the  ISO  In  developing  the  open  systems  Interconnection 
architecture  and  protocols.  The  Government  now  has  two  networks,  split, 
physically;  ARPANET  (tor  the  RAO  community)  and  MILNET  (for  D00  operational  users). 
Layers  of  protocol  functionality  between  the  DOD  and  the  ISO  agree  well  up  through 
the  transport  layer  (this  Is  based  on  both  supporting  at  least  connection- 
oriented,  connectionless  and  Internetworking  protocols).  Layers  of  protocol 
functionality  above  the  transport  provide  similar  services  but  are  very  different 
In  the  packaging  of  functions.  The  DOO's  approach  has  been  to  group  service 
functions/protocols  more  into  subsystems  whereas  the  OSI  has  maintained  clean 
separation  of  the  layers  for  session,  presentation  and  application.  This  has 
resulted  In  a  vertical  oackaglng  of  functions  by  000  (with  some  intermixing  of 
functions  across  layers  5,  6  and  7)  and  a  horizontal  packaging  Into  layers  by  OSI, 
with  some  added  Interface  formality  between  layers. 

This  vertical  packaging  of  protocol  layered  functions  Into  somewhat  of 
a  subsystem  Is  very  similar  to  the  way  IBM's  SNA  has  done  Its  higher  layer 
crotocols.  In  SNA  [82],  the  Transport  through  Applications  layer  protocols  are 
packaged  vertically  Into  what  Is  called  a  Logical  Unit,  or  LU.  The  LU  Is  made  up 
of  subfclements  of  layers  4-7  protocols  and  are  configurable  when  a  session  Is  set 
up.  LU's  are  given  Type  designations  (l.e.,  LU  0-6.2)  which  delineates  end  user 
properties.  The  000' s  approach,  based  upon  experience  emanating  from  the  ARPANET 
research  community,  has  characteristics  similar  to,  but  not  as  extensive  or  formal 
as,  the  SNA  Logical  Unit. 

5. 1 1 . \ . 1 . 3  Soft  Layering  of  Protocols 

Cooper  [43]  examined  the  issue  of  soft  layering  of  protocols  as  part  of 
his  masters  thesis  at  MIT  In  1983.  He  examined  the  Issue  of  the  efficiency  of 
protocol  layering.  He  found  t\’o  major  sources  of  Inefficiency  In  protocol 
Implement'  ;ionr  These  were  caused  by  "the  Imposition  on  them  of  a  layered 
structure." 

In  the  thesis  abstract  the  following  Is  stated: 

"The  conventional  approach  to  making  layered  protocol  Implementations 
run  efficiently  -  for  avoiding  the  sources  of  Inefficiency  -  are  all 
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independent  of  the  protocol  specification,  and  thus  all  decrease  the 
value  of  the  protocol  specification  as  a  guide  for  Implementing 
protocol  s-.  " 

The  report  "introduces  a  new  means  of  avoiding  the  problems  of  layered 
protocol  Implementations  which  operates  within  the  domain  of  the 
protocol  specification.  We  allow  an  increase  In  the  flow  of  state 
Information  between  the  layers  of  a  layered  protocol  Implementation  In 
a  very  controlled  manner  so  as  to  decrease  the  modularity  of  the 
protocol  architecture  as  little  as  possible.  Since  our  approach 
decreases  the  rigidity  of  the  layered  structure  without  entirely 
eliminating  It,  we  coin  the  term  "Soft  Layering"  for  the  approach." 
5.11.2  POD  Yersus  ISO  Models 

Figure  5.11.2  Is  a  simplistic  representation  of  the  DOD  and  OSI  layered 
protocol  architectural  models.  Organizations  which  participate  In  the  ISO 
networking  architecture/protocols  standards  making  work  are  numerous  throughout 
the  world.  Table  5.11.2  lists  only  a  few.  These  are  CCITT,  ECMA,  ANSI,  NBS, 

IEEE,  EIA,  DOO,  special  Interest  groups  and  Industrial  organizations.  On  the 
other  hand,  DOD  Is  more  of  a  closed  organization  without  the  participation  by  such 
a  cross  section  as  in  the  ISO. 
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Figure  5.11.2.  DOO  and  ISO  Reference  Models 
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Table  5.11.2.  Groups  Involved  In  Standards 


Groups  involved  In  standards 

imiwyv* T 

AfMMtoA 

Itw&rjMjiM 

Inftwnu 

ISO 

(International 

Standards 

Organization) 

international 

Voluntary,  nonlreaty 

Stan-vds  bodies  In 
pernopaiing  nations. 

U.S  representative 
«  ANSI;  ECMA  ia 

observer 

Responsible  tor  Open 

Systems  Interconnection 
model  Close  relationship 
with  CCITT 

CCITT 

(international 

Consultative 

Committee  on 
Telegraphy  and 
Telephony) 

International 

Part  ol  International 
Telecommunications 
Union  (a  u  N  treaty 
organization) 

Private  companies; 
scientific  and  trade 
*t  sooations;  postal, 
teiepnone.  and  tete- 
grapn  administrations. 

US  representative  is 
Department  ot  State 

-Recommendanons'' 
which  are  lew  where 
eommumcatione  m  Europe 
are  nationalized 

ECMA 

(European  Computer 

Manulacturers 

Association) 

Computer  suppliers 
selling  m  Europe, 
includes  some  u  S 
comp,  'lies 

Trade  organization 
ot  suppliers 
smalt,  mm  about 

20  members 

Contributes  lo  ISO  and 
also  issues  own  standards 
known  tor  last  movement 

Western  Europe 

ANSI 

(American  National 
Standards  institute) 

Un.tan  States 

Votuntiry 

Manufacturers. 
ofQtrwationt. 
users,  and 
communications 
earners 

U  S  voice  m  ISO 

NBS 

(National  Bureau 
o 1  Standards) 

United  States 

Government  Agency 

Government  agencies 
and  network  users, 
much  work  dene  by 

Bolt  Beranek  & 

Newman,  wtiich  is 
largety  responsible 
tor  DOO's  Arpanet 

Issues  Federal  Informa¬ 
tion  Processing  standards 
tor  equipment  sold  to 
federal  government. 

Department  cl  Defense 
need  not  comply 

IEEE 

(institute  ot 

Electrical  and 

Electronic  Engineers) 

Internationa: 

Professional  Society 

Dues -paying  individuals 

Contributes  to  ANSI  and 
issues  own  standards 
such  as  IEEE-002  3 

CSMA/CD  and  802  * 
token-bus  LANS  and 

IEEE -488  bus 

EIA  (Electronic 

IrxjL  lines 

A„.,r"iatior,) 

U  S  trade  organizavo 

Manufacturers 

Contributes  to  ANSI,  known 
tor  physical  layer's 

RS-232-C  .tandard 

United  States 

OOO  (Oepartntent 
ot  Defense) 

Government  Agency 

Government/mililary 

All  customers  dealing  with 
the  military  establishment 

United  States 

Soeoal  interest 
industry  grouos, 
sucn  as  me 

ANSi  X9  eanlting 

standardization 

group 

Vofuntary  organizations, 
such  as  ANSI  and  IEEE 

Organizations  and  firms 
with  a  specialized  mterost 

issues  standards  that 
meet  a  specialized  need 

Industrial 

organizations 

Self 

— 

Determined  by  market 
impecl 

An  Immediate  observation  Is  that  the  functional  decompos-ltlon  of  both 
Is  the  same  through  the  transport  layer.  It  1$  only  at  the  higher  layers  that 
dl t Yerences  appear. 

The  reason  for  this  could  be  that  the  functional  basis  for  the 
decomposition  changes  at  this  point.  Through  the  transport  layer  all  layer 
objectives  are  concerned  solely  with  the  transportation  of  data.  A  protocol  above 
this  layer  need  not  be  concerr.ed  with  physical  transmission,  routing.  Involvement 
or  existence  of  Intervening  nodes,  or  errors  detected  and  recoveries  made. 

Instead,  above  the  transport  layer,  the  objective  Is  the  accomplishment  of  a 
particular  tas'c.  Both  the  ISO  and  000  models  concern  themselves  with  this  overall 
goal,  namely,  the  ability  to  achieve  a  common  (distributed)  task. 

Recognition  of  a  functional  transition  above  the  transport  layer  Is 
Important.  It  forces  a  change  of  perspective.  The  higher  layer  protocols  look 
downward  to  the  transport  and  lower  layers  only  for  the  data  transmission  services 
necessary  for  the  accomplishment  of  their  distributed  tasks.  At  these  higher 
layers  there  Is  less  of  a  stratification  of  functions.  Instead  (and  particularly 
as  viewed  In  the  DGO  model),  there  appear  to  be  groupings  of  decidedly  different 
functions  within  the  same  layer.  This  Is  because  of  the  common  need  for  data 
transmission  services  but  the  differing  purposes  of  tasks. 

An  example  of  this  type  of  functional  transition  can  oe  found  In  our 
postal  system.  Here  the  mailbox  acts  as  the  Interface  between  the  data 
transportation  layers  and  the  task  oriented  layers.  Contents  of  mailed  letters 
can  be  viewed  as  task  data.  A  person  mailing  a  letter  Is  not  concerned  with  the 
method  of  transportation,  be  It  truck,  train,  or  plane.  The  concern  Is  only  that 
the  letter  arrive  at  Its  destination  In  some  reasonable  length  of  time.  This  Is 
the  service  upon  which  the  mailer  depends.  In  turn,  the  postal  department  has  no 
knowledge  of  the  contents  of  letters  (“talks'),  be  they  bills,  Invitations  or 
correspondence. 

5.11.2.1  Application  Layer  Differences  Between  ISO  and  DO!) 

ISO/RM:  Provides  a  superset  of  POD  services  and  Identifies  management 
services/ functions  more  explicitly  titan  does  000  for  application-processes  and  OSI 
system  resources.  ISO  adheres  to  formal  layering  structure. 

POD/RM:  Some  services,  such  as  establishing  authority  to  comnunlcate 
and  privacy  mechanisms,  have  been  partially  moved  to  the  session  layer.  As  D00 
requirements  mature,  greater  divergence  from  ISO  Is  expected.  Management 
services/functions  for  eppllcatlons-processes  and  000  resources  are  not  explicitly 
specified.  D00  applies  protocol  hierarchy  structure  rather  than  a  strict  layering 
structure. 
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5.11.2.2  Presentation  Layer  Differences  Between  ISO  and  POD 
ISO/RM 

1.  Views  a  resource  strictly  as  a  data  structure,  with  a  set  of 
commands  to  access  or  modify  the  data;  this,  according  to  00D, 
is  too  strict  a  view. 

2.  The  particular  transfer  syntax  is  negotiated  at  the  time  of 
connection  establishment,  whereas  In  DOD  a  default  syntax  Is 
defined  which  all  must  Implement,  plus  a  negotiating  capability. 

3.  Quality  of  service  Is  absent  in  ISO  but  Is  explicitly  addressed 
by  POD. 

NOTE:  ISO  model  stresses  point-to-point  two-party 
Interactions,  whereas  DOD  supports  multi -entries  distributed. 

5.11.2.3  Session  Layer  Differences  Between  ISO  and  DOD 
ISO/RM 

The  ISO  session  layer's  functions  are  seen  by  DOD  as  not  adding  very 
much  value  to  the  underlying  transport  layer  services.  In  addition,  volca  and 
other  real-time  stream  applications  are  not  adequately  supported.  ISO  only 
supports  point-to-point  communications  between  using  entitles  and  does  not  support 
connect-! onl ess  service. 

DOD/RM 

The  DOD  session  layer  differs  In  four  ways  from  ISO: 

1.  Support  for  real  time  quality  of  service  using  entitles,  for 
diverse  applications 

2.  Support  for  distributed  applications 

3.  Provisions  for  communication  between  more  than  two  entitles 

4.  Data  quantitative  has  been  dropped 

In  the  future,  D00  anticipates  needing  some  access  control  and  name 
service  functions  added,  as  well  as  Increased  robustness  and  control. 

5.11.2.4  Transport  Layer  Differences  Between  ISO  and  DOD 
ISO/RM 

ISO  transport  layer  protocols  are  currently  connection-oriented.  ISO 
has  less  negotiable  quality  of  service.  Session  layer  services  are  separate  from 
transport. 

DOD/RM 

A  major  difference  Is  that  DOD  stresses  use  of  connectionless 
(datagram)  UDP  service  as  well  as  connection  service  TCP  at  the  transport  layer. 
DOD  provides  greater  ability  to  negotiate  quality  of  service  In  order  to  support 
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wide  range  of  usage  (e.g.,  transaction,  bulk  transfer  and  real  tlae).  Son* 
session  layer  services  have  been  Merged  Into  transport  layer  services  In  DOD. 

5.11 .2.5  Internet  Layer  Differences  Between  ISO  and  DOD 

ISO/RM 

There  is  no  ISO  Internet  layer  but  X.75  Is  a  connection-oriented 
virtual  circuit  approach  residing  In  the  network  layer. 

DOD/RM 

The  000  approach  Is  different  from  ISO  fundamentally.  ISC’s  approach 
Is  based  on  X.75  type  connection-oriented  tandem  Interconnecting  of  subnetworks 
which  results  In  virtual  circuits  serially  connected  and  mapping  done  between 
them.  000,  rather.  Is  based  on  use  on  connectionless  datagram,  spanning 
end-to-end  through  gateways  which  join  different  method  subnets  together.  000 
uses  the  Internet  Protocol  (IP)  as  Its  Internetworking  standard.  This  Is  more 
robust,  survlvable  and  flexible  than  virtual  circuits  in  tandea.  D00  does  not 
preclude  using  connection-oriented  Internet  protocols 

5.11.2.6  Network  Layer  Differences  Between  ISO  and  DOT) 

ISO/RM 

The  view  Is  end-to-end  tandem  relays  of  Individual  subnetworks,  with 
emphasis  (currently)  on  connection-oriented  services  with  X.25  packet  switched 
services  as  the  primary  view. 

Internetworking  Is  viewed  to  be  done  In  an  upper  sublayer  of  the 
network  layer. 

DOO/RM 

The  view  Is  that  of  services  provided  by  a  single  network,  operating  as 
one  of  several  within  an  Internet,  with  emphasis  on  connectionless  (datagram) 
Internet  Protocol  users.  000  predicts  that  connectionless  (datagram)  local  area 
networks  will  predominate.  Internetworking  Is  done  in  a  separate  layer  above  the 
network  layer. 

5.11.2.7  Data  Link  and  Physical  Layers 

There  Is  essential ’y  no  difference  between  tne  000  and  ISO  reference 
models  for  the  Data  Link  and  Physical  layers  In  the  services  provided,  fhe  ISO 
has  developed  for  the  most  part  with  a  connection-oriented  perspective  ana  almost 
exclusive  use  of  carrier  based  network  facilities.  The  000  model  supports  both 
connection  and  connectionless  services  ana  recognizes  nr;re  than  just  public 
network  facilities.  The  000  recognizes  local  area  network  facilities  whereas  the 
ISO  model  1$  just  beginning  to  consider  the  use  of  LAN's.  ISO  currently  Is 
reviewing  the  IEEE  802  LAN  standards  for  International  use. 
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POD  Networking  Reference  Model 

The  POP  Protocol  Reference  model,  shown  fn  figure  5.12  and  Table  5.12, 
Is  Intended  to  document  the  principles  of  protocol  design.  It  Is  to  be  a  baseline 
serving  the  development  of  standard  POP  protocols.  It  attempts  to  describe 
ARPANET  and  Internet  programs  and  commercial  world  design  principles  and 
experiences.  It  attempts  to  prescribe  principles  for  development  of  future  POP 
protocols.  The  DO D/R.*n  diverges  from  the  OSI/RM  of  ISO  ir  that: 
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Figure  5.12.  POP  Internet  Protocol  Hierarchy 

1.  POD  has  specific  communications  requirements  (e.g.,  security, 
survivability). 

2.  OSI/RM  is  too  restrictive  on  the  designer. 

It  communicates  basic  principles  of  the  "OOP  approach  to  protocol 
design"  to  Interested  parties.  Lastly,  It  is  proposed  as  a  guide  to  the  basic 
direction  of  POD  protocol  specification  efforts. 
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Table  5.12.  DOD  Reference  Model  Layers 


e  Application  Layer  -  Protocols  provide  distributed  Information 
services  to  an  application,  to  Its  management,  and  to  system 
management 

e  Presentation  Layer  -  Protocols  provide  virtualization  of  data 
formats  and  distributed  resources 

e  Session  Layer  -  Protocols  help  coordinate  use  of  multiple  transport 
services,  provides  name  services  and  access  controllers 

e  Transport  Layer  -  Protocols  provide  process-to-process 
cownunl cation  across  one  or  more  networks  (Host-to-Host) 

e  Internet  Layer  -  Protocols  perform  network  to  network  routing 

•  Networx  Layer  -  Protocols  that  are  network-specific  that  allow  data 
transfers  over  a  single  network 

e  Data  Link  Layer  -  Protocols  manage  data  transfer  across  a  single 
data  link 

•  Physical  Layer  -  Protocols  that  manage  access  and  data  transfer 
with  a  physical  communications  channel 

The  general  strategy  followed  in  developing  the  D00  Protocol  Reference 
Model  was  to  use  the  ISO  Reference  Model  (RH)  for  Coen  Systems  Interconnection 
(OSI )  as  a  base;  a  second  major  Influence  was  the  ARPA  Internet  project.  Where 
the  OSI  baseline  was  thought  to  be  inadequate,  the  DOO/RM  reflects  modifications 
made  to  meet  particular  DOD  '•equirements.  The  DOD/RM  report  discusses  five 
specific  areas  that  affected  the  DOD/RM. 

•  Anticipated  DOD  network  applications 

•  Internetworking  with  present  and  planned  DOD  (and  non-DOD)  systems 

•  Security  requirements 

•  Robustness  and  other  DOD  quality -of-servlce  Issues 

e  Phased  evolution  from  existing  DOD  systems  and  protocols 

Since  the  OOD/RM  (and  many  of  the  associated  protocols)  Is  not 
completely  specified  at  this  time.  It  can  only  serve  as  a  guide.  Certain 
protocols  that  are  already  DOD  standards  are  Included  In  DOD/RM.  Other  protocols, 
while  not  yet  DOD  standards,  are  actively  under  development,  and  designers  should 
be  aware  of  these  efforts.  In  areas  where  no  specific  DOD  work  Is  under  way,  the 
work  of  national  and  International  standards  groups  should  be  monitored. 

Regardless  of  the  particular  protocols  employed,  the  principles  of 
layering  Imposed  by  the  DOD/RM  (and  the  OSI  RM)  should  be  scrupulously  observed. 
The  Interfaces  between  layers  should  be  Independent  and  modular  In  order  to  allow 
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protocols  at  the  various  layers  to  be  replaced  or  extended  when  It  Is  advantageous 
to  do  so  (e.g. ,  to  accommodate  new  applications).  Correspondingly,  the  protocols 
employed  In  the  LAM  architecture  should  follow  D00,  national,  and  International 
standards.  That  is,  only  vendor  Independent  (nonproprietary)  protocols  should  be 
considered  an  acceptable  approach. 

The  ARPANET /D00  architecture  and  protocols  suites  for  networking 
predates  the  work  of  the  ISO  in  developing  the  open  systems  Interconnection 
architecture  and  protocols,  The  Government  now  has  two  networks,  split  physically 
ARPANET  (for  the  RAD  community)  and  MILNET  (for  DOD  operational  users). 

Applications  Layer 

This  provides  the  means  for  application  programs  to  access  the  DOD 
Internetworking  environment  serving  as  the  windows  between  comiunlcatlng 
application  processes.  The  protocols  define  Information  transfer  semantics 
services.  The  evolution  of  a  multihost,  multivendor  LAN-based  command  center 
environment  will  likely  require  a  Conmon  Command  Language  Protocol  that  provides  i 
common  rser  Interface  to  network  functions.  Additionally,  NBS  work  In  the  areas 
of  Nelwv.rk  Interprocess  Communication  and  Distributed  Data  Protocols  should  be 
monitored  for  possible  later  Inclusion  In  a  LAM  Protocol  Architecture. 

Utility  Layer  (Presentations/Session) 

Performs  the  virtualization  of  data  and  resources,  preserving  meanings 
while  resolving  syntax  difference;,.  This  allows  users  to  transparently  manlpulatf 
remote  resources.  ODD  places  the  following  services  In  the  utility  layer(s): 

•  Virtual  terminal 

e  Virtual  file  store 

•  Distributed  data  base 

•  Teleconferencing 

•  Advanced  messaging 

It  Is  expected  that  the  above  protocols  will  provide  the  basis  for  the 
presentation  layer.  In  addition,  work  Is  proceeding  within  ISO  and  NBS  In  the 
areas  of  Virtual  Terminal  Services,  Job  Transfer  and  Manipulation  Services,  and 
Management  Protocols  that  should  be  monitored  for  possible  Inclusion  In  the 
LAN-based  Protocol  Architecture. 

The  Inclusion  of  a  Virtual  Terminal  Protocol  (VTP)  In  the  LAN  Protocol 
Architecture  Is  of  particular  Interest.  A  VTP  will  enable  new  terminals  to  be 
Integrated  quickly  Into  the  LAN  without  requiring  application  modifications;  only 
the  Interface  for  a  particular  terminal  type  need  be  aware  of  Its  specific 
characteristics.  The  objective  of  a  VTP  Is  to  accommodate  a  wide  variety  of 
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terminals  with  capabilities  varying  from  simple  character-oriented  transmission  to 
advanced  capabilities  such  as  color,  support  for  multidimensional  data  structures, 
and  graphics  (e.g.,  raster,  vector,  or  bit-map).  While  there  has  been 
considerable  research  on  VTP's,  for  example,  requiring  a  YTP  for  the  LAN  will 
entail  significant  developmental  risks,  due  to  Its  complexity  and  the  lack  of 
Implementation  experience  In  this  area. 

The  000  reference  model  Identifies  some  Important  deficiencies  In  the 
ISO  session  layer  services:  lack  of  support  for  nonrecord-oriented  transaction 
exchanges  (e.g.,  voice,  real-time  data  streams);  lack  of  quallty-of-servlce 
negotiation  between  the  session  layer  and  Its  users'  Inability  to  coordinate 
activities  of  more  than  two  presentation  layer  entitles  (e.g.,  conferencing).  The 
DOD/RM  describes  a  multipoint  notion  of  "session*  (different  from  that  of  the  ISO 
session  !?yer)  established  by  a  presentation  layer  entity  called  the 
"session-controller."  It  Is  anticipated  that  several  different  session  layer 
protocols  might  be  designed  and  Implemented  depending  on  the  applications  Involved 
Currently,  no  000  standard  specification  for  a  session  layer  protocol 
has  been  completed.  Work  Is  progressing  on  a  000  Session  Control  Protocol  (SCP), 
however.  The  session  layer  functions  required  by  existing  presentation  layer 
protocols  are  provided  by  TCP.  In  some  of  these  presentation  layer  protocols, 
additional  functions  usually  associated  with  the  session  layer  are  handled  by  the 
particular  presentation  layer  protocc1  As  a  result,  a  separate  session  layer 
protocol  Is  not  Initially  required.  Nonetheless,  the  LAN  protocol  design  should 
not  preclude  fully  distinct  transport,  session,  and  presentation  layer  Independent 
protocol s. 

TELNET  -  Virtual  Terminal  Protocol 

This  Is  a  byte-oriented  coomunl cations  facility  which  uses  a  TCP 
connection  for: 

e  Terminal  to  process 
e  Terminal  to  terminal 
e  Process  to  process 

Based  on  a  scroll  mode  ASCII  TTY,  the  protocol  defines  options 
negotiable  between  using  parties.  TELNET  does  not  provide  capabilities  for 
properly  using  newer  bit  mapped  displays  where  windowing  and  font  selection  are 
used.  One  approach  to  Improving  TELNET  Is  to  creat  a  new  class  of  virtual 
terminal  for  the  latest  terminal  technology  and  expansion  for  future  growth. 
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File  Transfer  Protocol  (FTP) 

Promotes  file  sharing  and  use  of  remote  computers  while  shielding  the 
user  from  variation  In  local  file  storage  systems.  TELWET  uses  two  TCP 
connections;  one  for  TELNET  to  set  up  conditions  of  control  for  Initiating  data 
transfer,  and  the  second  for  exchanging  the  file  data  across. 

FTP  transmission  modes  are  stream,  block,  and  compressed.  Limitations 
exist  with  handling  number  representation  and  word  length  between  processors, 
especially  with  floating  point  numDer  representation.  General  file  transfers 
between  widely  diverse  equipment  Is  limited.  In  handling  specialized,  extremely 
large  volumes  of  file  data  transfers,  development  of  new  protocols  might  be 
warranted.  Also,  the  protocol  should  relieve  the  user  of  having  to  supply  many  of 
today's  functions  by  including  type  Information  within  the  block  transfer  mode 
header. 

Internet  Name  Server 

This  uses  the  user  datagram  protocol  by  returning  an  Internet  address 
message  In  response  to  a  user  Initiated  name  request  message.  As  networks  for 
distributed  processing  grow,  a  more  general  distributed  system  of  name  servers  and 
their  protocols  needs  development.  This  needs  to  handle  multiple  Internet 
subnetworks,  nodes  and  those  that  will  be  mobile. 

Transport  Layer 

Provides  network -transparent  data  transfer  between  utility  layer 
users.  These  perform  end-to-end  functions  between  originating  and  destination 
hosts.  Two  major  types  of  service  are  provided;  connection-oriented  (for  streams) 
and  connectionless  (for  transaction  messages). 

The  Transmission  Control  Protocol  (TCP)  became  a  DOD  standard  protocol 
In  January  1980.  It  became  a  full  MIL-Standard  In  1983  [35].  TCP  provides  a 
reliable,  sequenced,  flow-controlled  channel  (virtual  circuit)  between  two 
processes.  TCP  Is  specifically  designed  to  operate  above  IP  and  Is  Intended  for 
use  In  packet-switched  networks  and  Interconnected  sets  of  such  networks. 

Within  Air  Force  and  some  strategic  DOD  LAN  protocol  architectures,  it 
Is  clear  that  TCP  will  be  the  primary  transport  layer  service;  however,  some 
applications  may  not  require  all  the  connection-oriented  features  of  TCP.  Other 
transport  services,  such  as  a  real-time  connection  service  that  offers  guarantees 
on  delay  and  delay  variance  and  a  connectionless  service  that  Is  either  reliable 
or  unreliable,  may  be  appropriate  for  some  applications.  For  example,  It  has  been 
suggested  that  some  of  the  functions  performed  In  the  Network  Voice  Protocol  would 
be  more  appropriate  to  a  general-purpose  real-time  transport  protocol.  The  User 
Datagram  Protocol  (UDP)  Is  a  real-time  transport  protocol  that  does  not  Impose  the 
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TCP  Virtual  circuit  mechanisms;  It  simply  augments  IP  with  source  and  destination 
port  addressing  and  checksumming  for  error  detection. 

Internetwork  Layer 

This  performs  the  end-to-end  routing,  switching,  fragmentation, 
reassembly  and  gateway  functions  needed  to  Interconnect  multiple  subnets 
together.  This  employs  a  connectionless  {or  datagram)  service. 

The  primary  00D  Internetting  strategy  Is  embodied  In  the  Internet 
Protocol.  IP  Is  a  datagram  Internetting  scheme  whereby  internet  datagrams  are 
routed  among  hosts  and  gateways  using  the  local  subnetwork's  Internal  routing 
mechanisms.  The  services  offered  by  IP  thus  clearly  are  the  model  for  the  "basic" 
connectionless  internet  service  as  described  In  the  DOD  network  Layer.  IP  would 
sit  In  the  "internet  sublayer"  of  the  Network  Layer  and  would  call  on  the  services 
of  the  protocols  within  the  "subnetwork  sublayer"  for  routing  within  a  subnetwork. 

The  Internet  Protocol  (IP),  which  became  a  DOD  standard  In  January  1980 
and  became  a  MIL-Standard  In  1983  [36],  uses  an  extended  finite  state  machine 
model.  The  primary  services  provided  by  IP  are  internet  routing  and  packet 
fragmentation  and  reassemDly.  IP  provides  several  features,  such  as  source 
routing,  the  "don't  fragment"  option,  and  certain  “type  of  service"  options,  that 
are  not  provided  by  other  "potential"  network  layer  protocols  such  as  the  NBS 
Internet  Protocol . 

DOD  must  also  allow  real-time  services  to  be  Incorporated  within  Its 
protocol  architecture.  At  the  Network  Layer,  this  requires  an  alternative  to  IP 
which  can  make  some  guarantee  as  to  the  delays  and  delay  variances  experienced  by 
user  data  as  It  traverses  the  Internet.  Such  a  service  can  be  accomplished  via  a 
connection-oriented  Internet  protocol  which  dedicates  gateway  or  subnetwork 
resources  on  a  per-connectlon  basis.  Although  a  general-purpose  real-time 
Internetting  protocol  has  not  been  developed  within  the  DOD  conmunlty,  the  ST 
protocol  used  In  the  Experimental  Integrated  Switch  Network  (EISN)  project  for 
voice  Is  a  good  Initial  model.  Such  a  real-time  Internetting  protocol  would  be 
similar  to  IP  In  that  It  uses  the  services  of  the  subnetwork- sublayer  Intranet 
routing  mechanisms  for  subnetwork  transport. 

Network  Layer  -  Provides  the  use  of  public  data  network  services  as  one 
type  of  subnet  under  the  Internet  layer. 

A  type  of  internetting  service  which  should  be  incorporable  within  the 
DOD  Network  Layer  Is  reliable  connection-oriented  service  typified  by  X.75.  The 
degree  of  "reliability”  offered  by  such  systems  is  generally  not  enough  to 
eliminate  the  need  for  end-to-end  mechanisms  with  the  Transport  Layer. 
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Consequently,  such  an  approach  to  Internetting  Is  not  anticipated  to  be  used 
heavily  by  000  applications.  However,  the  ability  to  Interoperate  with  public 
networks  necessitates  that  the  DOD  Network  Layer  not  preclude  such  a  service. 

Data  Link  Layer  -  Provides  for  the  reliable  transfer  of  data  units 
across  e  link  connecting  two  nodes.  This  can  be  be  multipoint,  point-to-point,  or 
a  local  area  network. 

Physical  Layer  -  Provides  the  means  to  access  the  physical  medium 
through  which  data  communication  occurs. 

5.13  ISO  and  IEEE  802  Networking  Reference  Models  and  Protocols 
5.13.1  Introduction 

The  International  Standardization  Organization  (ISO)  has  established  a 
model  of  protocol  architecture  based  on  a  seven  layer  structure  [5].  This  model 
Is  known  as  the  Open  Systems  Interconnection  Reference  Model  (OSI/RM). 

The  basic  architecture  specified  by  the  OSI  Reference  Model  Is  only  the 
first  In  a  family  of  standards  that  will  result  from  this  work.  From  the 
established  principles  of  OSI,  layer  service  definitions  are  now  being  developed 
that  will  then  enable  further  development  of  the  necessary  protocols  for 
communications  among  distributed  application  processes  within  the  Open  Systems 
Interconnection  structure. 

The  definition  of  the  OSI  scope  and  standards  started  In  the 
mid-1970's,  and  a  set  of  standards  covering  different  layers  of  the  OSI  model 
should  become  available  by  the  mid-1980's.  The  environment  and  the  objective  to 
be  addressed  by  OSI  have  been  defined  as  follows  [5]. 

"In  the  concept  of  OSI,  a  system  Is  a  set  of  one  or  more  computers, 
associated  software,  peripherals,  terminals,  human  operators,  physical 
processes.  Information  transfer  means,  etc.,  that  forms  an  autonomous 
whole  capable  of  Information  processing  and/or  Information  transfer. 

OSI  Is  concerned  with  the  exchange  of  Information  between  open  systems 
(and  not  with  the  Internal  functioning  of  each  Individual  open 
system).  OSI  Is  concerned  not  only  with  the  transfer  of  Information 
between  systems,  l.e. ,  transmission,  but  also  with  their  capability  to 
work  together  to  achieve  a  common  (distributed)  task.  In  other  words, 
OSI  Is  concerned  with  cooperation  between  systems,  which  Is  Implied  by 
the  expression  'systems  interconnection'.  The  objective  of  OSI  Is  to 
define  a  set  of  standards  to  enable  open  systems  cooperation.  A  system 
which  obeys  applicable  OSI  standards  In  its  cooperation  with  other 
systems  Is  termed  open  system." 
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0S1  defines  the  external  communication  capability  of  a  system  to  make 
It  an  open  system*,  l.e.,  capable  of  cooperating  with  other  open  systems  according 
to  OSI  standards.  The  normal  0S1  applicability  Is  In  cases  where  the  operating 
open  systems  each  have  a  different  Internal  architecture. 

The  advent  of  OSI  standards  will  bring  a  new  dimension  to  the  current 
environment  by  providing  universally  agreed  upon  means  of  permitting  communication 
and  cooperating  between  (or  among)  heterogeneous  systems  and  products.  The 
existing  systems  will  progressively  Implement  OSI  capability  In  response  to  user 
application  needs.  But  the  existence  of  OSI  standards  should  not,  and  will  not, 
slow  down  the  increasing  number  and  diversity  of  heterogeneous  systems  and 
products.  In  fact.  In  response  to  users'  requirements,  the  systems  built  on 
heterogeneous  architectures  will  grow  in  number  and  In  size  and  they  will  even 
provide  new  functions  that  are  not  supported  by  OSI  standards. 

The  resulting  OSI  environment  will,  therefore,  be  characterized  by  a 
large,  and  possibly  increasing,  diversity  of  heterogeneous  open  systems; 
heterogeneous  because  they  are  built  on  different  architectures;  and  open  because 
they  are  capable  of  cooperating  with  other  systems  by  Implementing  the  OSI 
protocols. 

The  layers  of  the  OSI/RM  are  described  (briefly'  In  Table  5.13.1. 

The  upper  three  layers  provide  the  functions  In  direct  support  of  the 
application  process,  while  the  lower  three  layers  are  concerned  with  the 
transmission  of  the  Information  between  the  end-systems  of  the  communication.  The 
Transport  layer  Is  the  essential  link  between  these  two  groups  of  functions;  It 
provides  end-to-end  Integrity  of  the  communication,  ensuring  that  the  appropriate 
quality  of  service  from  the  lower  three  layers  meets  the  requirements  of  the  upper 
three  layers. 

For  any  system  to  operate  properly,  there  must  be  orderly  management  to 
ensure  all  components  work  In  harmony.  The  management  aspects  of  OSI  Include  the 
control  of  Initiation,  termination,  monitoring,  and  handling  of  abnormal 
conditions.  There  are  three  management  areas  that  need  to  be  considered. 

-  Application  management  -  Involves:  Initialization  of  parameters; 
Initiation,  maintenance,  and  tennlnatlon  of  the  communication; 
detection  and  prevention  of  OSI  resource  interference  and  deadlock; 
Integrity  and  commitment  control;  security  control;  and 
checkpointing  and  recovery  control. 

-  Systems  management  -  Involves  control  of  the  OSI  resources  and 
their  status  across  all  the  layers. 
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Table  5.13.1.  Layers  of  Cpen  System  Interconnection  Reference  Model 


APPLICATION  LAYER 


Directly  serves  AP  by  providing  access  to  the  Open  Systems  Interconnection 
Environment  and  provides  the  distributed  information  services  to  support  the 
AP  and  manage  the  communication. 

PRESENTATION  LAYER 

Provides  the  services  that  allow  the  AP  to  interpret  the  meaning  of  the 
information  being  transferred  -  syntax  selection  and  conversion. 

SESSION  LAYER 

Supports  the  dialog  between  cooperating  AP's,  binding  and  unbinding  them  Into 
a  communicating  relationship. 

TRANSPORT  LAYER 


Provides  end-to-end  control  and  information  interchange  with  the  reliability 
and  auali-y  of  servlet  that  Is  needed  for  the  AP. 

NETWORK  LAYER 

Provides  the  switching  and  routing  functions  needed  to  establish,  maintain, 
and  terminate  switched  connections  and  transfer  data  between  the 
communicating  end-systems  (NOTE  -  The  term  "network-  as  used  here  Is  a 
specific  OSI  technical  term  and  should  not  be  taken  as  denoting  a 
communications  network  In  the  conventional  sense.) 

DATA  LINK  LAYER 


Provides  for  the  transfer  of  information  over  the  physical  link  with  the 
necessary  synchronization,  error  control,  and  flow  control  functions. 

PHYSICAL  LAYER 

Provides  the  functional  and  procedural  characteristics  to  activate,  maintain, 
and  deactivate  the  physical  links  that  transparently  pass  the  bit  stream  of 
the  communication. 


NOTE:  AP  denotes  applications  process. 
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-  Layer  management  -  Is  concerned  with  the  activation  process,  error 
control,  and  coordination  of  activities  within  a  layer. 

The  OSI  Reference  Model  presently  deals  only  with  a  connection-oriented 
mode  of  operation.  That  Is  were  a  path  for  the  comunlcatlon  to  follow  is 
established  prior  to  the  communication.  A  connectionless  mode  of  operation  also 
has  some  popularity  and  Is  being  prepared  as  an  addendum  to  the  OSI  Reference 
Model.  Connectionless  communications  do  not  preestabiish  a  path,  but  route 
Individual  units  of  Information  as  they  are  sent.  The  optional  datagram  service 
In  CCITT  Recommendation  X.25  Is  an  example  of  connectionless  operation,  while 
virtual  circuit  service  Is  an  example  of  a  connection-oriented  communication. 

5.13.2  IS0*s  Open  System  Interconnection  (OSI)  Architecture  and  Protocol  Suite 

-  The  Purpose  of  OSI  -  To  allow  any  computer  anywhere  In  the  world  to 
conminlcate  with  any  other,  as  long  as  both  obey  OSI  protocol 
standards.  The  OSI  Reference  Model  Is  an  abstract  description  of 
Interprocess  communications. 

-  The  OSI/RM  -  Defines  types  of  objects  that  are  used  to  describe  an 
open  system,  the  general  relations  among  these  types  of  objects, 
and  the  general  constraints  on  these  types  of  objects  and 
relations.  The  document  which  describes  the  OSI  architecture,  ISO 
7498,  defines  these  objects,  relations,  and  constraints,  and  also 
defines  a  seven-layer  model  for  Interprocess  communication 
constructed  from  these  objects,  relations,  and  constraints. 

-  A  Service  Specification  -  Represents  a  lower  level  of  abstraction 
that  defines  the  service  provided  by  each  layer.  Tighter 
constraints  on  the  protocol  and  the  Implementation  that  will  satisfy 
the  requirements  are  given.  It  defines  the  facilities  given  to  the 
user  and  an  abstract  Interface  for  each  protocol  layer  by  specifying 
the  primitives  the  user  would  Invoke  to  access  the  service. 

-  Protocol  Specifications  -  Represent  the  lowest  level  of  abstraction 
In  the  OSI  standards  scherne.  Each  protocol  specification  defines 
precisely  what  control  Information  Is  to  be  sent  and  what 
procedures  are  to  be  used  to  Interpret  this  control  Information. 

The  protocol  specifications  constrain  Implementations  sufficiently 
to  allow  open  systems  to  communicate  while  still  allowing 
differences  In  Implementation. 
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-  Conformance  to  the  OSI  Reference  Model  -  Will  not  assure 
Interoperability  among  end  systems;  only  confonsance  to  the  OSI 
protocols  will  assure  open  systems  Interoperability. 

-  OSI  Intent  -  Is  not  to  standardize  the  Internal  operation  of  a 
system  but  rather  the  conmunlcatlon  between  systems- 

fn  the  OST/RM  -  Communication  takes  place  between  application 
processes, running  In  distinct  systems  In  which  a  system  Is 
considered  to  be  one  or  more  autonomous  computers  ind  their 
associated  software,  peripherals,  and  users  that  are  capable  of 
Information  processing  and/or  transfer. 

-  In  the  OSI/RM  Architecture  -  All  services  provided  tc  the 
application  process  users  are  grouped  into  seven  subsystems  of 
protocol  layers,  whose  entitles  are  distributed  aixng  the 
interconnected  systems  and  which  communicate  by  message  exchange 
among  entities  of  equal  layer  In  the  structure  according  to  formal 
rules  of  communications  cal’ed  peer  protocols.  This  layering 
technique  Is  similar  to  the  one  used  in  structured  programming, 
where  only  functions  performed  by  a  module  (and  not  its  Internal 
functioning)  are  known  by  its  users. 

-  Layer  Services  -  These  are  the  capabilities  which  a  layer  provides 
to  a  user  of  that  layer.  Within  a  layer,  functions  will  be 
performed,  some  of  which  are  not  user  provided  services.  Only 
capabilities  seen  by  the  user  are  the  services. 

-  Layered  Functions  -  These  are  the  activities  which  are  performed 
wlthir  a  layer.  Functions  are  performed  by  layer  entitles  through 
cooperation  with  other  layer  entitles  distributed  throughout  the 
network.  Entities  of  equal  layer  value  ecmmunlcate  ty  peer 
protocols. 

-  Layer  Service  Access  Points  -  Abstract  perts  through  which  users 
request  and  receive  the  services  provided  by  a  particular  layer. 

5.13.3  Seven  PCI  Protocol  Layers 

This  provides  a  discussion  of  the  seven  OSI  protocol  layers.  Table 
5.13.3  Identifies  the  corresponding  functions  of  each  layer  [173.  Figure  5.13.3 
Illustrates  the  composite  OSI  model  and  status  of  protocol  developments  [18]. 


'  A 

•  . 


'  .  W 
* 

'  .  \ 


1785D/LAN 


5-93 


K 

rf 

,N 

% 

> 


l 

> 

V 

’v 

-J 

i 


■j 


v' 


17C5D/LAN 


Table  5.13.3,  Functions  of  the  OSI  Layers 


Functions  of  the  OSI  layers 


Appbcation  ley* 

CorTknon  eppko two  service  elements 
Lopr> 

Pmm rd  checks 

Set  y  assocaoons  »  named  peers  and  agms  on  the  semantic#  ct 
tie  Morme&on  to  be  exchanged 
Specific  appficrMr.  service  elements 
File  transfer  end  file  access 
Osset  dess  virtual  lemvnai 

Forms  class  vetuel  terminal  (i/ider  development  by  ECMA) 

Message  hendkng 

Oucumem  trander 

Job  transfer  snd  manipulation 

Videotex) 

Graprxcs  (semantics) 

Comnunmeof.  concurrency,  snd  recovery 

Purchase  orders 

Banking  protocols  | 

CredS  checking  protocols  j  indusJy  protocols 

invoce  pr.nocois  j 

Inventory  protocols 

Pmsentsaon  layer 

Nagcksfe  transfer  syntax  lor  character  sets,  text  amps,  data  cksptay 
formats,  graphics  syntax,  Ife  organization.  Oats  types,  financial 
rtormahon 

Session  layer 

Connection  estaOWhment  and  temwiaten 

Cats  muster 

Synchronization  between  and-ussr  tasks 
Qracatu  and  abrupt  closure 

Mao  addmeet  to  names  (users  ratsn  same  name  r  they  move) 
Dialog  control  (who.  when,  how  long,  halt  or  M  duplex) 

Ouarandrang  ot  data  (buttering  or  nala  unw  instructed  to  dekver  i ) 

transport  layer 

Add  use  end-use*  mecfvnes  wkhoul  concern  tor  route  ot  message  or 
sddress  at  machetes  an  route  between  end-uaar  mechrwe 
Muaplrx  and-uaer  address  onto  network 
End-to-end  error  detection  and  recovury 
Moneomg  ot  quakty  or  service 
PoesMy  (ksassemftte  and  reassert*  session  massages 

Network  layer 

Set  up  routes  lor  packets  to  travel  (estabksh  s  vrtusr  cecut) 

Address  nerwork  mectwies  on  me  route  through  which  bie  packets 
travel 

May  deessembte  transport  messages  eko  peckers  snd  leessempte 
them  si  tie  destinetio n 

Send  control  messages  to  peat  layers  about  own  status 
Flow  control  (regulate  the  rate  af  which  a  mschns  receives  mettagus) 
Recognize  massage  pnonoes  and  sand  messages  n  proper  priority 
order 

Inlemetworlung 
Deta-knk  control  layer 

Add  fiegs  to  rxkcaie  begum«*g  and  end  ot  metasqss 
Add  error -checking  sigrnmms 
Make  sure  data  e  not  mistaken  lor  Hags 
Provide  access  methods  lor  local  area  networks 

Physical  taver 

Henke  vottages  snd  electrical  pulses 

Hand*  cables  Conner  ton  and  components 

Hand*  cotWoi  detection  ‘or  CSMA/CO  access  method 
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Flgure  5.13.3.  Composite  OSI  Model 
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-  Application  Layer  -  This  deals  with  the  semantics  of  the 
application;.  It  Is  the  uppermost  region  of  the  L  /RM  containing 
not  only  OSI  services,  functions  and  protocols,  but  the  application 
processes  themselves;  the  users  of  complete  OSI  services.  The 
basic  OSI  services  are  a  set  of  genetic  networkl ng-type  utilities 
plus  the  common  application  service  elements.  OSI  generic  services 
being  standardized  are  protocols  for  Virtual  File,  Virtual 
Terminal,  Job  Transfer/Manipulation  and  Management  of 
Appllcatlon/System  Resources.  Other  application  services  beyond 
these  OSI  offerings  are  needed,  but  Industry  groups  will  develop 
these  for  their  specific  needs.  In  terms  of  the  GNOS  object 

(resource)  based  architecture  model,  the  OSI  generic  services  ^ 

provide  a  set  of  networking  utllitles/orococols  which  support  the 
GNOS  resource  managers.  1 

Presentations  Layer  -  Thi s  deal s  wl th  the  syntax  or  data  C 

representation  for  the  semantics  of  the  users  application  data  to 
be  transferred  through  the  network.  The  user  may  use  an  existing 
context  or  define  Its  own  and  register  It  with  the  ISO. 

'  Session  Layer  -  This  deals  with  organizing  and  managing  the  data 
being  exchanged  between  application  processes,  the  establishing  of 
synchronization  points  and  the  definition  of  special  tokens  for 
structuring  exchanges. 

*  Transport  layer  -  Thi s  provl des  for  the  transparent  transfer  of 
data  between  end  systems.  It  optimizes  use  of  any  underlying 
network  service  and  provides  the  overall  end-to-end  reliability  for 
communications.  Two  types  of  services  have  been  Identified; 
connection-oriented  (for  data  streams)  and  connectionless  (for 
message  transactions). 

-  Network  Layer  -  This  provides  for  the  relaying,  routing,  switching 
and  internetworking  across  the  heterogeneous  subnetworks  (among 
concatenated  networks). 

-  Data  Link  layer  -  Thi s  provl des  the  means  for  transferrl ng  data 
between  network  entitles  and  detecting  and  correcting  for  possible 
errors.  Data  links  may  be  'tipoir.*.,  point  to-polnt  or  a  local 
area  network. 

-  Physical  layer  -  This  provides  the  means  to  access  the  physical 
medium  spanning  nodes  of  the  OSI  system. 
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-  Media  Lay  err  -  This  Is  not  a  separate  OSI  formalized  layer  but  does 
represent  peer  protocol  functions  which  are  performed  by  modulated 
signalling  exchanges,  to  transfer  digitized  data  through  a  medium. 
5.13.4  IEEE  Project  802  Protocols  Suite  for  Local  Area  Networks 

This  subsection  provides  a  discussion  on  the  IEEE  302  LAN  protocols. 
Reference  [41]  provided  the  basis  for  the  findings  which  follow.  In  addition  to 
attendance  at  the  November  1983  meetings  held  In  Silver  Spring,  HO. 

5.13.4.1  General 

The  Institute  of  Electrical  and  Electronic  Engineers  Standards 
Committee  802  has  been  working  for  the  last  4  years  to  develop  standards  for 
shared  -edlum  local  area  networks.  Four  of  these  standards  have  been  approved  an 
others  are  nearing  completion. 

A  local  network  Is  a  system  for  Interconnecting  computer,  terminal,  or 
peripheral  data  stations  so  they  can  communicate  In  a  local  environment  -  a  set  o 
buildings,  an  office  campus,  or  a  manufacturing  complex  where  all  of  the  devices 
are  within  a  few  Kilometers  of  each  other.  It  Is  possible  that  several  local 
networks  may  exist  In  the  same  setting. 

Any  local  network  will  permit  a  station  to  attach  to  a  medium  for  the 
purpose  of  transmitting  and  receiving  dat>.  Shared  medium  »ocal  networks  are 
local  networks  with  one  further  requirement:  they  must  permit  several  different 
Information  processing  systems  to  concurrently  use  the  medium.  There  Is  normally 
no  master  station  or  controller  of  the  medium  (sucn  as  a  PBX)  In  a  shared  medium 
local  network.  Therefore,  access  to  the  medium  must  be  autonomous. 

The  physical  Interfaces  and  protocols  of  shared  medium  local  networks 
are  designed  for  efficient  operation  over  short  distances  (a  few  kilometers)  uslr 
high-quality  media  (shielded  twisted  pair,  coax,  optical  cable)  resulting  In  low 

Q 

error  rates  (on  tlie  order  of  one  In  10  bits).  Data  rates  are  high  -  above 
1  Mb/s  -  permitting  many  data  stations  (on  the  order  of  200)  to  share  a  single 
local  network  transmission  medium. 

The  basic  motivation  for  standardizing  shared  medium  local  networks 
stems  from  the  customer's  desire  to  minimize  the  cost  (and  duplication)  of 
installing  and  maintaining  several  different  networks.  Shared  medium  local 
networks  permit  different  computer  systems,  each  with  Its  own  terminals  and 
peripherals,  to  attach  and  concurrently  use  the  same  physical  medium.  This  Is  a 
first  step  towards  the  eventual  goal  of  sharing  expensive  peripheral  devices  amoi 
different  computer  systems  on  the  same  medium.  This  goal,  however,  requires 
standardization  of  higher  layer  protocols. 
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Standards  are  being  developed  for  baseband  and  broadband  bus  media 
using  a  contention  method  called  carrier  sense  multi  -access  with  collision 
detection  (CSMA/CD)  (IEEE  802.3),  for  baseband  media  using  a  token  ring  access 
method  (IEEE  802.5),  and  for  baseband  and  broadband  bus  media  using  a  token  bus 
access  method  (IEEE  802.4).  A  baseband  medium  can  be  defined  as  i*  single  medium 
capable  of  carrying  a  single  Information  channel.  A  broadband  medium  Is  a  single 
medium  capable  of  carrying  multiple  Information  channels,  similar  to  a  community 
access  television  (CATV)  system. 

Some  standards  efforts  are  further  along  than  others;  for  example, 
development  has  just  begun  for  a  metropolitan  area  network  standard  (ItEE  802.6). 

A  metropolitan  area  network  Is  a  form  of  local  network  that  stretches  the  meaning 
of  "local,"  since  It  encompasses  a  radius  of  up  to  25  kilometers  (using  CATY  or 
other  media). 

All  of  the  shared  medium  and  medium  access  standards  have  been 
specified  to  work  under  the  control  of  a  single  Logical  Link  Control  (LLC) 
standard  (IEEE  802.2),  capable  of  providing  connectionless  and.  If  required, 
connection  service  for  any  one  of  the  shared  media  or  media  access  methods. 

Finally,  a  standard  for  higher  layers  of  shared  medium  local  networks 
(IEEE  802.1)  Is  being  developed  to  specify  a  consistent  method  for  internetworking, 
addressing,  and  managing  local  networks  and  for  addressing  at  (and  possibly  above) 
the  network  layer.  This  standard  will  also  be  used  as  a  companion  document  to 
soeclfj  the  relationship  between  all  of  the  other  IEEE  802  standards. 

5.1?, 4. 2  Physical  and  Link  Layers  of  IEEE  802 

P'-n  has  not  established  standards  for  LAN  physical  and  link  layers. 
However,  ror  guidance  In  this  area,  consideration  should  be  given  to  the  work  by 
?'BS,  which  pi s  to  complete  a  local  area  network  Interface  standard  for  the 
Federal  Government,  and  to  the  work  by  the  IEEE  802  Local  Networks  Standard 
Committee.  ong  the  International  organizations,  the  European  Computer 
Manufacturer-  Association  Technical  Committee  24  is  producing  local  network 
standards  based.  In  part,  on  the  IEEE  802  work. 

The  IEEE  802  committee  has  recently  reached  full  IEEE  final  approval  of 
several  of  Its  Local  Network  Standards.  It  defines  a  multipoint,  peer-to-peer 
communications  network,  where  all  communications  are  a  "single  hop"  without 
Intervening  switching/routing  nodes.  The  scope  of  this  LAN  standard  Includes,  In 
OSI  terms.  Layers  1  and  2  and  the  medium  (see  Figure  5.13.4.2-1).  Note  that  the 
IEEE  802  specification  does  not  define  how  a  LAN  IU  should  be  constructed.  The 
specification  defines  a  logical  external  Interface  via  multiple  service  access 
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Figure  5.13.4.2-1.  IEEE  LAN  Reference  Model 
points  (SAP's)  to  the  next  higher  (Layer  3)  protocol  entity  and  not  a  physical 
external  Interface  to  a  user  device. 

The  IEEE  802  Local  Network  specifications  consist  of  five  principal 

parts: 

•  Service  Access  Points  (SAP's)  -  Service  Access  Points,  for 
addressing  end  points,  are  defined.  To  support  multiple  Network 
Layer  protocols,  LLC  Service  Access  Points  (L-SAP's)  provide 
interface  ports  at  the  Network/LLC  L^yer  boundary  (3/2  Interface). 
The  Medium  Access  Control  SAP  (MAC-SAP)  provides  a  single  Interface 
port  at  the  MAC/LLC  boundary.  The  Physical  Service  Access  Point 
(P-SAP)  provides  an  Interface  port  to  a  single  MAC  entity. 

•  Logical  Link  Control  (LLC)  Sublayer  -  The  Logical  Link  Control 
procedures  are  derived,  In  part,  from  ISO's  HDLC.  Two  types  of 
link  service  are  defined:  Connectionless  and  Connection-oriented. 
Connectionless  service  allows  two  LLC  stations  to  exchange  frames 
without  establishing  a  logical  link.  Frames  can  (optionally)  be 
acknowledged,  but  there  are  no  flow  control  or  error  recovery 
procedures.  Connection-oriented  operation  causes  a  logical  link  to 
be  established  before  any  exchange  of  user  data.  Error  recovery. 
In-sequence  delivery,  and  flow  control  are  provided.  A  pair  of  LLC 
SAP's  serve  to  Identify  the  stream  of  data  units  exchanged  between 
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two  Network  Layer  users.  Management  services  (e.g. ,  link  layer 
status  reporting)  are  also  defined  for  this  layer. 

a  Medium  Access  Control  (MAC)  Sublayer  -  Two  access  methods  are 
supported:  CSMA/CD  and  Token  Passing.  Carrier  Sense  Multiple 
Access  with  Collision  Detection  (CSMA/CD)  Is  a  probabilistic  method 
for  assessing  the  medium.  Token  passing  provides  a  deterministic 
method  for  accessing  the  medium.  The  MAC  sublayer  also  provides 
functions  such  as  frame  checking  and  the  discarding  of  data  . 
fragments. 

e  Physical  Layer  -  The  Physical  Layer  provides  the  capability  to 
transmit  and  receive  modulated  signals  across  the  medium.  It 
defines  the  electrical  and  mechanical  characteristics  of  the 
physical  medium  attachment  and  physical  signaling  unit.  Including 
the  modulation  and  signaling  techniques  (e.g.,  Vestigial  Sideband 
(VSB)  modulation,  Manchester  signal  encoding).  Each  type  of  medium 
has  a  .'ledlum  Dependent  Interface  (MOD.  As  an  option  for  CSMA/CD 
networks,  the  Physical  Signaling  (PLS)  unit  may  be  separated  from 
the  Physical  Medium  Attachment  (PMA)  by  an  Access  Unit  Interface 
(AUI )  cable  of  up  to  50  meters  In  length. 

•  Medium  -  Options  for  the  medium  Include  75  ohm  broadband  cable,  50 
and  75  ohm  baseband  cable,  and  150  ohm  twisted  wire  pairs;  fiber 
optic  cable  specifications  have  not  been  completed. 

Figure  5.13.4.2-2  illustrates  the  options  available  In  the  IEEE  802 
Local  Network  Standard. 
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While  the  IEEE  802  options  are  extensive,  not  all  the  options  can  be 
Independently  selected.  For  example,  selecting  one  type  of  medium  access  method 
also  necess*tates  a  particular  medium.  Figure  5.13.4.2-3  organizes  the  physical 
layer  options  according  to  the  three  primary  types  of  local  network  technologies 
(CSMA/CD,  token  bus,  and  token  ring)  recognized  by  the  IEEE  802  LAM  standard. 
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5.13.4.3  8aseband,  Broadband  Standards  of  IEEE  802 

TWo  forms  of  CSMA/CD  standards  are  being  prepared  by  the  IEEE  802; 
baseband  and  broadband. 

CSMA/CD  Baseband  (802.3) 

The  CSMA/CD  baseband  network  standard  specifies  an  Interconnection 
technique  for  data  stations  to  share  access  to  a  50-ohm  baseband  coaxial  cable 
bus.  The  system  corresponds  topologically  to  a  branching  nonrooted  tree.  The  bus 
operates  at  a  data  rate  of  10  Mb/s.  Data  are  Impressed  upon  the  bus  using  a 
Manchester  encoding/decoding  technique. 

The  carrier  sense  part  of  the  CSMA/CD  medium  access  protocol  means  that 
before  transmitting  a  message,  a  user  data  station  must  monitor  the  bus.  If  the 
bus  Is  active,  the  station  must  wait.  When  activity  ceases,  the  station  may, 
after  a  short  delay,  transmit  Its  message.  The  station,  however,  must  also 
monitor  the  bus  (for  a  period  equal  to  the  propagation  time  of  the  bus)  to  ensure 
that  no  other  station  Is  also  transmitting.  This  Is  collision  detection. 

If  no  collision  Is  detected,  the  message  Is  transmitted.  If  a 
collision  Is  detected,  the  data  station  "jams"  the  bus  by  transmitting  a 
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detectable  signal,  then  terminates  the  message  transfer  and  requeues  the  message. 
It  collision  Is  again  detected,  the  station  Increases  the  delay  exponentially,  up 
to  a  limit.  The  process  continues  until  a  maximum  number  of  collisions  Is 
reached,  at  which  point  higher  layer  protocols  are  advised  of  the  problem. 

Each  station  monitors  the  bus  for  Its  destination  address  (or  an 
all -parties  address  or  a  group  address).  If  a  station  detects  a  message  with  Its 
destination  address.  It  captures  and  queues  the  message  for  a  higher  layer  Input 
process. 

Since  It  Is  possible  to  concurrently  operate  multiple  logical  data 
links  on  the  medium.  It  1$  necessary  to  provide  both  a  destination  and  a  source 
address  in  the  medium  access  layer  protocol.  The  standard  permits  two  address 
lengths:  a  16-bit  address  for  purely  local  addressing,  or  a  48-bit  address  when 
(Internetwork)  addresses  of  global  significance  are  desired. 

The  802.3  baseband  CSMA/CO  standard  was  approved  by  the  IEEE  Standard 
Board  In  June  1983. 

CSMA/CO  Broadband  (802.3) 

Efforts  to  develop  this  standard  are  still  In  their  early  stages.  The 
CSMA/CO  Working  Group  has  begun  to  specify  an  Interconnection  technique  for  data 
stations  to  attach  to  a  broadband  coaxial  cable  bus  and  to  share  access  to  one 
particular  subchannel  of  the  broadband  bus. 

In  order  to  achieve  two-way  transmission  on  a  broadband  system,  either 
dual  cables  or  a  remodulator/translator  device  is  required.  A  remodulator 
receives  data  from  any  one  of  the  data  stations  transmitting  on  subchannel 
frequency,  shifts  It  to  a  higher  frequency,  and  retransmits  the  data  down  the  same 
coaxial  cable.  The  data  stations  transmit  on  the  lower  frequency.  The 
remodulator  Is  normally  located  at  the  transmitter  end,  or  head  end,  of  the 
coaxial  cable.  The  topology  corresponds  to  the  rooted  tree  (became  of  the 
remodulator)  with  branching. 

Two  broadband  CSMA/CO  systems  are  under  consideration.  The  first  would 
operate  at  a  data  rate  of  10  Mb/ s  and  Is  Intended  to  use  a  larger  portion  of  the 
existing  broadband  standard.  A  bandwidth  at  least  equivalent  to  two  Tv  channels 
will  be  required  to  transmit  the  signal  over  a  CATV  cable  system. 

The  second  system  Is  optimized  for  broadband  operation  at  a  data  rate 
of  5  bto/s,  so  that  It  would  require  at  most  the  bandwidth  of  a  single  TV  channel. 

Submission  of  broadband  CMSA/CO  draft  standard  to  the  IEEE  Technical 
Committee  on  Computer  Communications  Is  not  expected  until  1984  at  the  earliest. 
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The  Baseband  Token  Ring  Standard  (802, 5 ) 

The  draft  token  ring  standard  being  developed  by  IEEE  802  specifies  a 
point-to-point  ring  topology  and  a  token-passing  access  method.  The  token  ring 
baseband  standard  specifies  an  Interconnection  technique  for  stations  to  share 
access  on  a  topological  ring.  Lower-speed  (1  Mb/s  to  4  Mb/s)  stations  are 
interconnected  In  a  point-to-point  manner  using  150-ohm  shielded  twisted  pair 
media,  while  higher-speed  stations  require  Interconnection  with  coaxial  cable  or 
optical  fiber.  The  modulation  technique  used  Is  Differential  Manchester. 

The  token  ring  requires  that  when  an  operating  data  station  Is  not 
originating  data  transmission,  it  must  repeat  the  data  that  It  receives.  Medium 
access  Is  controlled  by  means  of  a  token  that  Is  passed  from  station  to  station, 
and  grants  the  holder  the  right  to  transmit  Information  on  the  ring.  A  station 
passes  the  token  to  1 cs  physical  successor  when  It  has  no  more  data  to  transmit, 
or  when  a  token-holding  timer  has  expired.  The  token-holding  timer  prevents  one 
station  from  hogging  the  ring. 

As  each  data  unit  is  passed  around  the  ring,  a  data  station  that  has  a 
message  queued  for  transmission  Is  permitted  to  make  a  priority  reservation  by 
modifying  three  bits  In  a  header  that  eventually  Indicates  the  highest  priority  of 
messages  queued  by  all  other  members  of  the  ring.  If  the  message  priority  of  the 
repeating  device  Is  greater  than  the  priority  held  In  the  received  "reservation" 
bits,  the  device  may  modify  the  reservation  bits  to  Indicate  Its  higher  Drlorlty 
request.  If  the  priority  of  the  device  Is  less  or  equal  to  the  received 
reservation  bits,  no  modification  Is  made.  When  tiie  message  Is  returned  to  the 
transmitting  station  (the  token  holder),  the  priority  of  the  reservation  Is 
noted.  When  the  token-holding  station  has  complete  Its  transmission,  either 
because  It  has  exhausted  Its  priority  data  or  because  the  token-holding  timer  has 
expired,  a  free  token  Is  Issued  whose  priority  Is  set  to  either  the  highest 
reservation  received  or  the  priority  of  the  originally  received  free  token, 
whichever  is  greater. 

8oth  16-bit  and  48-bit  addressing  are  permitted  by  tne  token  ring  local 
network  standard. 

When  completed,  tne  IEEE  802.5  token  ring  draft  standard  will  be  sent 
to  the  IEEE  TCCC  for  review  and  ballot.  If  accepted,  the  draft  standard  will  be 
sent  to  the  IEEE  Standard  Board,  which  may  approve  the  standard  before  mld-1984. 
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Token  Bus  Standards  (802.4) 

The  draft  IEEE  802  token  bus  standard  defines  an  Interconnection 
technique  for  devices  to  share  access  on  a  physical  topological  bus.  The  standard 
defines  protocols  used  by  the  physical  and  medium  access  control  layers.  Interfaces 
between  those  layers,  and  Interfaces  to  the  medlua  and  to  higher  layers. 

The  IEEE  802  token  bus  standard  has  been  written  to  Include  both 
baseband  and  broadband  systems.  The  Intent  of  producing  a  single  standard  for 
these  two  media  Is  to  permit  an  easier  transition  from  baseband  to  broadband  local 
network  systems,  with  little  change  In  the  Installed  medium  or  termination 
equ1|iment. 

The  IEEE  802.4  token  bus  baseband  and  broadband  draft  standards  have 
already  received  an  affirmative  ballot  from  the  IEEE  Standard  Board. 

Baseband  Token  Bus 

This  standard  specifies  an  Interconnection  technique  for  devices  to 
attach  to  a  75-ohm  baseband  truck  coaxial  cable  bus,  and  to  share  access  to  that 
bus  using  a  token-passing  medium  access  protocol.  Bus  operations  at  data  rates  of 
1  Mb/s,  5  Mb/s,  10  Mb/s,  and  20  Mb/s  are  specified.  The  standard  specifies  two 
different  modulation  techniques.  Lower-speed  (1  Mb/s)  systems  use  Differential 
Manchester  encoding  with  phase  modulation  frequency  shift  keying.  Higher-speed 
(5  Mb/s  and  10  Mb/s)  systems  directly  encode  the  data  using  a  phase  coherent 
modulation  technique. 

Either  16  or  48  bit  source  and  destination  addresses  may  be  used  as 
station  addresses  In  the  baseband  token  bus  medlua  access  protocol. 

The  token  bus  medium  access  protocol  Is  similar  to,  but  must  differ 
from,  that  used  In  the  token  ring  since  the  medium  does  not  form  a  physical  ring. 
Therefore,  the  token  cannot  simply  be  passed  to  the  next  physical  data  station. 

The  token  must  be  logically  addressed  to  a  particular  data  station,  known  as  the 
transmitting  station's  “successor."  The  transmitting  station  must  maintain  the 
addresses  of  Its  predecessor  and  successor  station  so  It  can  maintain 
token-passing  operation  on  the  bus  in  case  of  failure. 

A  multiple-level  priority  mechanism  is  built  Into  the  token  bus  medium 
access  protocol.  Cut  unlike  the  token  ring,  where  a  new  priority  request  can  be 
made  as  each  data  unit  passes  around  the  ring,  the  token  bus  priority  mechanism 
requires  that  priority  be  based  upon  a  higher  (above  medium  access)  level 
agreement  among  the  token  bus  stations,  and  requires  additional  Individual  data 
unit  transmissions  among  the  stations  to  set  up  and  maintain  that  agreement. 
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Broadband  Token  Bus 

The  token  bus  broadband  standard  specifies  an  Interconnection  technique 
for  devices  to  attach  to  75-ohm  broadband  coaxial  cable  bus.  The  data  stations 
use  a  token  access  protocol  to  share  a  particular  broadband  subchannel  of  the 
medium.  Use  of  two  separate  physical  broadband  access  cables,  one  for  the  data 
stations  originated  transmissions,  one  for  head  end  originated  transmission,  Is 
also  permitted,  but  not  recommended.  In  the  IEEE  802  broadband  token  bus  standard. 

The  token  bus  broadband  subchannel  may  operate  at  data  rates  of  1  Mb/s, 
5  Mb/s ,  or  10  Mb/s.  At  1  Mb/s,  one  fourth  of  a  standard  6-MHz  CATV  channel  Is 
required  to  carry  the  data  from  the  data  station  to  the  head  end  to  the  data 
station. 

At  5  Mb/s,  one  standard  6-megahert*  tv  channel  Is  required  to  carry  the 
data  from  the  data  station  to  the  head  end,  and  another  b-MHz  channel  Is  required 
to  carry  the  data  In  the  other  direction.  At  10  Mb/s  the  channel  width 
requirement  Is  doubled. 

A  single  method  of  data  modulation  Is  used  In  this  broadband  token 
system.  It  Is  a  variant  of  Duobinary  AM/PSK,  and  requires  the  encoding  and 
detection  of  three  levels  of  amplitude  that  a-'e  used  to  distinguish  between  symbol 
codes. 

The  medium  access  control  protocol  used  for  broadband  token  bus  Is 
Identical  to  that  used  for  the  baseband  system,  with  some  additional  functions 
required  to  Interface  with  the  head-end  remodulator. 

5.13.4.4  Metropolitan  Area  Networks  (802.6) 

The  IEEE  8C2  executive  committee  has  received  permission  to  expand  Its 
charter  to  write  standards  for  metropolitan  area  networks  operating  over  distances 
of  5  to  50  kilometers  at  data  rates  at  or  above  1  Mb/s.  Several  proposals  for  MAN 
standards  have  been  made  to  the  MAN  Standard  Committee,  Including  systems  using 
broadband  cable  TV,  fiber  optics,  and  packet  radio.  Possible  services  to  be 
provided  are  bulk  data  transfer,  digitized  voice,  compressed  video,  videotex,  and 
transaction  service.  This  standard  Is  In  the  Initial  definition  stage. 

It  Is  anticipated  that  metropolitan  area  networks  may  provide  access  to 
local  networks  and  also  serve  as  a  means  of  access  to  satellite  or  other  wide  area 
networks.  The  approval  cycle  for  the  metropolitan  area  network  standard  Is  not 
expected  to  begin  before  1985. 

5.13.4.5  Logical  Link  Control  Standard  (802.2) 

The  standards  discussed  previously  define  a  physical  means  to  attach  a 
data  station  to  a  medium  and  an  access  method  protocol  for  sharing  the  use  of  that 
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medium.  Any  link  protocol  could  be  used  to  transmit  data  unit  messages  across  the 
medium,  provided  It  Is  enveloped  In  one  0/  the  medium  access  protocols.  Because 
the  standard  calls  for  an  autonomous  medium  access  protocol.  It  Is  possible  to 
operate  several  Independent  (logical)  links  concurrently  over  the  same  medium, 
using  the  same  medium  access  protocol.  The  user,  however,  may  want  a  single  data 
station  to  be  able  to  concurrently  operate  on  several  different  logical  links 
through  the  same  single  connection  to  the  medium. 

If  this  Is  the  case,  the  station  must  have  a  method  to  multiplex, 
demultiplex,  and  otherwise  sort  out  the  data  from  the  multiple  concurrent  data 
links  that  arc  Intended  for  different  users  In  that  station. 

The  IEEE  802  logical  link  control  standard  specifies  protocols  to 
control  one  or  more  logical  links  on  a  single  medium,  through  a  single  physical 
attachment  of  each  station  to  the  medium,  using  a  common  medium  access  method. 

The  logical  link  control  protocol  uses  the  following  standard  protocols:  CSMA/CD, 
token  ring,  token  bus,  or  metropolitan  area  network. 

The  logical  link  control  protocol  permits  the  multiplexing  to  and  from 
up  to  128  distinct  logical  links  In  the  destination  (and  source)  data  station. 

The  number  of  logical  links  actually  maintained  Is  a  function  of  the  resources 
(buffering  and  control)  available  In  the  data  station. 

Two  forms  of  logical  link  protocol  service  (control)  are  defined  In  the 
standard  Connectionless  service  Is  required;  connection  service  is  optional. 

Connectionless  logical  link  service  Is  similar  to  datagram  service, 
where  the  receipt  of  a  link  data  unit  transmission  Is  not  acknowledged  via  the 
logical  link  protocol.  It  is  assumed  that  data  units  are  acknowledged  at  some 
higher  protocol  level,  and  that  retransmissions,  when  required,  are  requested  by  a 
higher-level  protocol.  It  Is  assumed  that  the  medium  bandwidth  Is  adequate  to 
streamline  the  transmission  of  data  over  highly  reliable  local  networks. 

Connection  service  Is  similar.  In  fact,  almost  Identical,  to  the  type  ! 

of  service  provided  by  an  X.25  balanced-mode  link  layer  protocol.  Acknowledge  nt  i 

of  data  units  and  flow  control  both  exist  at  the  link  level.  Connection  service  ! 

requires  higher  operational  overhead  at  the  link  level,  but  assures  that  the 

1 

logical  link  can  operate  without  overloading  the  limited  buffering  capacity  of  the  I 

data  station.  ; 

Several  Implementors  Intend  to  envelop  other  (c'dar)  link  protocols  ' 

(SDLC,  bisync)  within  the  IEEE  802  logical  link  control  protocol  In  order  to 
provide  migration  paths  to  permit  older  equipment  to  be  multiplexed  onto  a  shared  ’ 

medium  local  area  network.  * 

l 
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The  IEEE  802.2  logical  link  control  draft  standard  has  been  approved  by 
the  IEEE  Board.  The  U.S.  National  Bureau  of  Standards  plans  to  Issue  a  standard 
that  specifies  only  the  connectionless  form  of  IEEE  802.2  logical  link  control. 

An  ad  hoc  group  of  Implementors  met  together  periodically  at  the 
National  Bureau  of  Standards  during  the  past  year  and  decided  to  attempt  to 
demonstrate  Interoperability  of  a  common  medium.  This  was  accomplished  at  the 
National  Computer  Conference  In  July,  1984.  All  systems  used  an  IEEE  802  medium 
and  medium  access  protocol  working  under  a  connectionless  IEEE  802  logical  link 
protocol,  with  CSMA/CC  and  token  bus. 

5.13.4.6  Higher  Layer  Interface  (802.1) 

When  originally  established,  the  function  of  the  higher  layer  Interface 
group  (IEEE  802.1)  was  to  write  a  companion  document  for  the  more  detailed  IEEE 
802  standards  to  explain  the  overall  intended  architecture.  But  In  the  process  of 
developing  these  Individual  standards,  it  was  determined  that  a  number  of  similar 
problems  existed  in  and  between  these  standards,  particularly  In  the  areas  of 
addressing,  gateways,  internetworking,  and  network  management.  The  work  of  the 
IEEE  802.1  group  was,  therefore,  expanded  to  standardize  these  areas. 

A  gateway  Is  a  device  used  to  forward  data  units  between  two  different 
local  networks,  or  between  a  local  network  and  a  wide  area  network.  The  protocols 
used  by  the  Individual  (local  or  wide  area)  networks  may  or  may  not  be  the  same. 

To  transmit  data  from  one  of  these  networks  to  another,  a  gateway  device  must 
extract  data  units  from  the  source  network,  buffer  them,  and  retransmit  them  onto 
the  destination  network.  At  the  same  time,  differences  In  protocol  must  be  Ironed 
out  at  the  gateway  (which  corresponds  to  the  network  layer  of  open  system 
archl tecture) . 

The  source  and  destination  local  network  networks  may  be  at  the  same 
site,  In  which  case  Identical  addressing  structures  may  be  used.  Alternately,  the 
two  local  networks  may  be  at  different  sites,  using  different  addressing 
structures  that  require  address  transformation.  Finally,  the  local  networks  may 
use  the  services  of  a  wide  area  network,  requiring  yet  another  addressing 
transformation,  as  well  as  a  protocol  change.  These  problems  are  being  considered 
by  IEEE  802.1  members  as  they  begin  to  write  the  addressing  and  Interconnection 
portion  of  their  standard. 

The  architecture  portion  of  the  draft  IEEE  802  higher  layer  Interface 
standard  (802.1)  will  soon  be  sent  to  the  IEEE  Technical  Committee  on  Computer 
Communication  for  review  and  ballot.  If  accepted,  this  portion  of  the  standard 
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will  be  sent  to  the  IEEE  8Q2  Standard  Board,  and  ipprovtl  could  occur  In  1984. 

The  addressing  and  Internetworking  portion  of  the  IEEE  802.1  draft  standard  Is  not 
expected  to  enter  the  review  process  before  late  1984. 

5.14  A  US  I  100  Mb/s  Token  Ring  UN  Standard 

5.1 4.1  Introductl on 

This  reports  on  new  work  under  way  In  the  ANSI  X3T9.5  Committee 
developing  a  standard  for  a  LAM  operating  ten  times  faster  than  the  IEEE  802.  The 
standard  Is  called  tne  Fiber  Distributed  Data  Interface  (FDD1).  This  discussion 
Is  based  upon  reference  [94]. 

5.14.2  Discussion  of  FODI 

The  IEEE  802  body  now  specifies  top-end  data  rates  tf  10  Mb/s  for  Its 
local  networks.  The  American  National  Standards  Institute  (ANSI),  however,  Is 
developing  network  standards  for  data  rates  an  order  of  magnitude  higher  -  around 
100  Mb/s.  These  are  not  futuristic  speeds.  Most  companies  Involved  In  developing 
these  standards  plan  to  Introduce  products  supporting  such  data  rates  during  1985 
and  are  pushing  to  finalize  the  standard  by  nld-1984.  Called  the  Fiber 
Distributed  Data  Interface  (FDOI),  this  proposed  new  ANSI  standard  (currently  In 
committee  X3T9.5)  specifies  a  token-passing  ring  architecture  for  local  networks 
using  optical  fiber  cable. 

There  are  two  reasons  for  the  need  for  high  data  rate  networks:  a 
dramatic  Increase  in  computer  processing  power  over  the  last  few  years  and  an 
enormous  Increase  In  the  volume  of  stored  or  processed  data.  As  a  result.  It  Is 
the  lower-speed  local  networks  that  quickly  become  the  weak  link  between  devices 
needing  to  transfer  huge  amounts  of  data  as  quickly  as  possible. 

Clearly,  data  rate  requirements  depend  or.  the  service;  supplied  and  the 
network's  application.  For  example,  back-end  networks,  which  connect  computers  to 
other  storage  devices  and  peripherals,  require  high-speed  data  transfer.  These 
networks  have  a  fairly  small  number  of  nodes  (frequently  fewer  than  50),  and  span 
relatively  small  distances  -  usually  within  a  computer  room.  In  general,  a 
backbone  network  has  to  be  at  least  as  fast  the  devices  on  It  In  order  to  minimize 
buffering  constraints.  As  the  speeds  of  hard  disks  and  optical  disks  Increase 
beyond  40  or  50  Mb/s,  back-end  networks  need  to  be  even  faster.  In  addition, 
protocols  for  such  networks  must  provide  for  "streaming''  operations.  In  which 
several  data  packets  are  sent  end-to-end  In  a  single  network  access.  This  Is 
essential. 
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Unlike  back-ends,  front-end  networks  typically  connect  computers  tu 
devices  that  are  more  user-interactive,  such  as  terminals,  word  processors, 
workstations,  and  printers.  Front-end  networks  can  have  hundreds  of  .nodes 
spanning  a  few  kll  ters.  The  IEEE  802.3,  802.4,  and  802.5  standards  are 
essentially  designs  or  front-end  applications. 

Until -row  users  have  been  satisfied  with  data  rates  of  10  Mb/s  or  so 
for  front-end  networks,  put  If  it  were  available  -  and  affordable  -  most  network 
users  would  welcome  higher  data  rates  and  their  services. 

For  example,  a  10-Mb/s  data  rate  Is  not  sufficient  to  support  many 
real-time  voice  conversations,  much  less  video  traffic.  But  as  the  need  for  these 
features  increases  with  deve’opments  such  as  teleconferencing,  higher  data  rates 
seem  much  more  attractive.  On  a  more  practical  note,  low-speed  networks  are 
usually  adequate  for  terminals  and  printers,  but  fo**  engineering  workstations, 
which  require  many  huge  file  transfers  dally,  a  high-speed  front-end  network  Is 
almost  essential. 

The  FDDI  Is  a  100-Mb/s  token-passing  physical  ring  using  fiber-optic 
cable.  The  ANSI  X3T9.5  committee  specifies  this  as  a  local  network  standard.  And 
various  corporate  architects  of  FDOI  plan  to  use4t  for  their  own  products  because 
the  standard  includes  features  that  support  the  many  applications  required  for 
high  marketability. 

For  example,  some  would  use  FDDI  for  back-end  computer  room 
applications  where  the  network  need  only  span  several  meters.  Others  Intend  to 
use  FUDI-based  products  for  connections  with  circumferences  of  over  100 
kilometers.  The  FDDI  specification  places  no  lower  bounds  on  the  number  of  nodes 
and  the  distance  between  them;  at  the  same  time,  the  upper  limits  are  reasonably 
large,  permitting  a  wide  range  of  Implementations.  Some  of  the  main  limits  are: 

e  Up  to  1,000  nodes  on  the  ring 

•  *Jp  to  2  kilometers  between  two  nodes 

•  Up  to  200  kilometers  ring  circumference 

With  the  maximum  1,000-node  configuration,  the  average  node  separation 
will  be  200  meters  In  order  to  limit  the  ring  circumference  to  200  k’lometers. 

Yet  several  nodes  may  be  separated  by  up  to  2  kilometers  as  long  as  the  average 
separation  Is  200  meters. 

These  limits  are  Imposed  to  minimize  latency,  or  the  time  It  takes  a 
signal  to  travel  around  the  ring.  The  maximum  ring  latency  Is  an  important 
parameter  for  some  real-time  network  applications.  And  with  the  proposed  FDDI 
standard.  It  Is  held  to  only  a  few  milliseconds. 
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The  FDDI  ping  Is  a  combination  of  two  independent  counter-rotating 
rings,  each  running  at  100  Mb/s.  If  both  rings  operate  simultaneously,  the 
effective  throughput  Is  200  Mb/s.  An  FDDI  scheme  can  actually  use  a  special  case 
of  this  where  one  ring  connects  all  the  nodes,  and  the  second  counter-rotating 
ring  only  a  selected  few. 

Figure  5.14.2  illustrates  a  possible  FDDI  network  configuration  with 
fiber-optic  cables  forming  the  inner  and  outer  rings.  The  paths  through  which  the 
data  travels  around  the  ring  are  also  shown.  The  ring  that  reaches  all  of  th* 
nodes  Is  called  the  secondary  ring  and  carries  data  In  the  opposite  direction  of 
the  primary  ring.  The  primary  ring  connects  only  the  Class  A  stations  (an 
explanation  of  station  classes  can  be  found  below).  Such  a  concentric  scheme  Is 
useful  during  ring  reconfiguration.  If  the  outer  ring  falls,  for  Instance,  the 
network  can  continue  operating  on  the  Inner  ring  and  still  keep  the  Intact 
portions  of  the  outer  ring. 


Figure  5.14.2.  FDDI  100  Mb/s  LAN  Topology 
Primary  and  secondary  fiber  rings  transmit  lightwave  data  In  opposite 
directions.  Class  A  stations  -  either  mainframes  or  wiring  concentrators  - 
connect  to  both  the  primary  and  secondary  rings.  Class  8  stations  connect  only  to 
the  primary  ring.  Fiber  cable  1  s -terminated  with  bulkhead  connectors. 
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1.16  Air  force  Flexible  Intraconneet  local  Area  Metevork  (FILAN) 

5.18.1  Intro duett on 

In  the  last  3  years,  Martin  Marietta  Denver  Aerospace  has  been  under 
RADC  contract  to  design4  develop,  and  document  a  high-capacity, 
processor -control led,  bus-oriented  local  area  network  (LAN).  This  effort 
encompassed  the  development  of  a  military  standard  Interface  specification 
(MIL-STD-1779)  fer  high-capacity  LAN's  and  a  prototype  baseline  Flexible 
Intraconnect,  local  area  network  (FILAN).  FILAN  Is  Intended  to  establish  the 
communications  foundation  for  current  and  evolutionary  C^I  systems  of  the  future. 

FILAN  was  developed  to  simultane uusly  service  a  wide  variety  of 
numerous  user  equipment,  such  as  processors,  peripherals,  terminals,  displays, 
voice,  video,  radar,  many  military  and  commercial  telecommunications  Interfaces, 
wide  area  networks,  and  other  local  area  networks.  Operational  features  of  FILAN 
Include  high  availability,  flexibility,  expandability,  and  a  system  manager 
Interface  that  provides  both  extensive  user  services  and  user-friendly  man-machine 
Interface. 

5.15.2  System  Overview 

FILAN  Is  a  high-capacity  LAN  and  is  shown  in  Figure  5.15.2.  It  is 
designed  for  use  In  military  C^I  systems  to  provide  highly  reliable  datagram  and 
Internet  services  over  a  single  local  subnet  (LSN)  or  interconnection  of  LSN's 
dependent  on  user  requirements.  Interfaces  to  the  FILAN  are  in  accordance 
MIL-STD-1779  ( USAF) .  For  users  not  compatible  with  MIL-STD-1779,  adaptation  via  a 
programmable  Interface  converter  (PIC)  Is  provided. 

FILAN  Is  a  bus-oriented  LAN  that  employs  a  prioritized  polling  scheme 
to  exercise  deterministic  bus  access  control.  FILAN  offers  extensive  network 
management  capability  that  allows  rapid  on-line  (re)configuratlon  of  the  network, 
withconstant  performance  monitoring,  and  fault-detection/isolation  to  protect 
against  component  unit  (CD)  failures  and  local  traffic  overloads. 

The  LSN  Is  comprised  of  three  basic  components: 

LTC  (Local  Subnet  Token  Controller) 

NAU  (Network  Access  Unit) 

LSM  (Local  Subnet  Medium) 

The  LTC  Is  the  LSN  controller  -  Its  primary  functions  are  to  poll  and 
store  the  polling  schedule  and. to  ( reconfigure  the  LSN  after  the  network  manager 
has  defined  the  configuration. 
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The  NAU  Is  the  connection  between  the  MIL-STD-1779  Interface  and  the 
bus  -  Its  primary  functions  are  to: 

Provide  access  for  multiple  virtual  users  at  the  MIL-STD-1779 
Interface 

Provide  datagram  services  to  Its  host  users 
Perform  MIL-STD-1779  message  validation  (header  contents, 
header /data  error  checking  and  control,  message  size,  and  delivery 
time  checkl ng,  etc. ) 

5.15.3  Air  Force  Workshop  on  Flexible  Intraconnect  Local  Area  Network  (FILAN) 

This  reports  on  attendance,  by  Invitation,  at  the  Air  Force's  (RADC) 
workshop  on  the  FILAN,  under  development  by  Martin  Marietta  -  Denver.  The 
wo-kshop  was  held  on  March  28-29,  1984  In  Denver,  Colorado. 

A  Joint  Air  Force  -  Martin  Marietta  conducted  workshop  was  held  for  the 
first  time  to  inform  people  of  the  current  status  of  the  development  of  the 
Flexible  Intraconnect  Local  Area  Network  (FILAN).  There  were  approximately  125  In 
attendance. 

The  following  were  the  main  results  obtained  from  the  workshop: 

1.  Martin  Marietta  and  Hughes  were  awarded  dual  study  contracts  In 
1977  for  FILAN.  RADC  selected  Martln'-s  approach  and  awarded  the 
development  contract  in  1981. 

2.  The  work  to  date  represents  Advanced  Development  Models  with 
demonstration  at  90  Mb/s,  with  a  goal  of  180  Mb/s,  over  ribbon 
cable  and  fiber-optic  media.  These  are  owned  by  the  Air  Force. 

3. *  Extensive  hardware  and  software  documentation  was  developed. 

4.  A  MIL-STD-1779  was  developed.  This  provides  a  parallel  DMA  type 
I/O  transfer  mechanism  for  users  to  access  the  FILAN. 

5.  Internally,  the  FILAN  provides  a  reliable  polled  datagram  access 
method  service  encompassing  the  Physical,  Data  Link,  and  Subnetwork 
layers  contained  In  the  Open  Systems  Interconnection  Reference 
Model.  However,  the  specific  protocols  employed  are  not  OSI 
compatible  and  are  not  open  protocols. 

6.  Up  to  64  Network  Access  Units  (Nodes)  are  supported,  each  capable 
of  supporting  14  user  ports.  Up  to  64  FILAN  subnets  can  be 
combined  Into  a  global  LAN  system. 

7.  A  centralized  management  with  distributed  control  operation  Is 
employed. 
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8.  Bridge  links  enable  Interconnecting  FILAN  subnets  together. 

9.  The  current  ADM  models  of  the  Network  Access  Units  employ  12 
Plug-In  Circuit  Boards  In  one  rack  mounted  chassis. 

10.  Users  are  expected  to  Implement  the  MIl-STD-1779  Interface  in  the 
long  term.  In  the  Interim,  Programmable  Interface  Converters 
(PIC's)  perform  the  adaptation  from  the  nonstandard  to  the  standard 
Interface.  A  single  PIC  requires  13  Plug-In  Boards. 

11.  The  current  FI  LAN's  NAU's  are  media  Independent,  but  a  parallel 
ribbon  cable  and  a  fiber-optic  media  have  been  Implemented.  The  Air 
Force  hopes  later  to  standardize  a  Physical  to  Media  Interface(s). 

12.  Media  access  Is  done  by  a  central  "deterministic"  polled  bus  access 
method  performed  by  a  Local  Subnet  Token  Controller.  The  services 
of  point-to-point,  multi -point,  token  ring  and  broadcast  are 
supported. 

13.  Traffic  handling  Is  stated  to  be  200C  messages  per  second  per  NAU, 
(1000  In,  1000  out)  where  each  message  can  be  up  to  4K  x  16  bits  of 
user  data  (128  Mb/s  per  NAU). 

14.  Higher  Layer  protocols,  such'as  the  DOD's  TCP/IP,  would  be  treated 
transparently  by  FILAN  through  encapsulation  and  decapsulation. 

15.  Network  Management  currently  Is  done  on  a  VAX  11/780  machine.  A 
wier  console  Is  provided  which  enables  one  to  specify  and  configure 
thfe  system,  reconfigure,  and  run  tests/gather  status  data.  All  NAU 
software  Is  down  line  loaded. 

16.  Fiber-optic  media  work  employs  a  fragmented  star,  supports  64 
stations  at  2K  meters  diameter  across  the  LSN.  A  laser  is  employed 
and  uses  only  an  80  bit  turn-on  preamble.  Expansion  to  256 
stations  was  stated. 

17.  FILAN  was  stated  to  be  a  software  Intensive  system.  Forty-thousand 
lines  of  code  have  been  developed,  about  half  In  FORTRAN  and  the 
balance  In  assembly  language. 

18.  Current  FILAN  hardware  employs  12-13  Plug-In  Boards.  Power 
dissipation  per  NAU  Is  360  watts.  Uses  Schottky  Bipolar  TTL 
devices.  Uses  a  dual -ported  high-speed  memory  between  user  1/0  and 
bus  media  accessing.  INTEL  8086,  8089,  I/O  Processor  and  Slgnetlcs 
8  x  300  devices  used. 
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19.  Next  generation  FILAN,  called  the  Basic  FILAN  Unit  (BFU),  trill 
employ  VLSI,  “C"  language,  IEEE  796  Multibus,  Fiber-Optic  Media, 
and  new  INTEL  186  and  286  devices,  aimed  at  reducing  NAU  from  1? 
down  to  3-4  Plug-In  Boards  and  might  have  a  cost  of  about  $1  OK 
each.  It  needs  to  have  MIL-STD-1 779  i/F  chips  developed. 

20.  There  currently  Is  a  FILAN  test  demonstration  Installed  at  the 
NORAD  Software  Development  facility  and  Is  undergoing  evaluation. 

5.15.4  FILAN  In  a  Multi-Media  Environment 

The  FILAN  to  date  Is  media  bound  to  flat  ribbon  cable.  A  fiber-optic 
link  was  demonstrated  at  the  FILAN  workshop.  In  a  tactical  envl roiraent  other 
forms  of  media  will  be  needed  to  Interconnect  FILAN  Local  Subnets  and  Individual 
nodes  together.  A  new  Multi-Media  LAN  (MM. AN)  study  has  been  initiated  by  RADC 
with  the  Harris  Corporation  to  develop  a  system  definition  for  MMLAN. 

5.16  Effects  of  LAN  Protocol  Characteristics 

This  subsection  discusses  the  results  obtained  from  studies  of  the 
literature  which  reported  on  the  effects  of  LAN  characteristics,  such  as  topology, 
transmission,  traffic,  access  method  and  throughput-delay  performance.  The  IEEE 
802  LAN  Medium  Access  Methods  formed  che  basis  of  most  of  the  results. 

5.16.1  Topological  Effects  [34] 

The  common  topologies  for  LAN's  are  star,  ring  and  bus,  plus 
combinations  of  these.  While  there  are  specific  applications  for  which  each  of 
these  might  be  best  suited,  some  general  qualities  of  their  topologies  for  comnand 
and  control  need  to  be  considered. 

With  a  star,  the  central  switching  node  is  a  single  failure  point.  The 
central  node  Is  also  the  limiting  factor  on  throughput  and  number  of  virtual 
connections  f^’t  can  be  maintained.  A  ring  with  single  direction  transmission  Is 
subject  to  l  .llura  If  any  node  falls  oecause  all  traffic  must  pass  through  all 
nodes  between  the  source  and  destination.  A  ring  with  bidirectional  transmission 
is  subject  to  fragmentation  when  more  than  one  node  falls.  Passive  "bypasses"  can 
alleviate  the  effects  of  ring  node  failures,  although  the  "reconstruction"  of  a 
damaged  ring  Is  difficult  because  of  problems  In  restoring  the  token  to  a  known 
state.  Rings  allow  broadcast  transmission  and  are  expandable  (but  not  without 
temporarily  halting  operation).  Performance  Is  somewhat  sensitive  to  size  of  the 
rl  ng. 
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■  Bus  topologies  can  have  either  central  or  distributed  control,  with 
distributed  control  being  more  common  and  generally  wore  useful.  Single  nod' 
failures  affect  only  that  node,  due  to  the  watchdog  tlner  used  to  monitor  thr 
transmitter.  In  bus  systems  using  collision  detection  transmission  schemes. 
Intermittent  failures  tend  to  be  treated  as  collisions  (because  both  result  In 
checksum  error)  and  are  simply  corrected  through  retransmission.  Although  there 
are  technological  limitations,  expansion  can  be  achieved  with  amplifiers, 
repeaters,  and  taps  up  to  the  bandwidth  of  the  medium.  Buses  lend  themselves 
either  to  straight  line  topologies  or  tree-like  topologies,  depending  on  the 
transmission  technology  used  and  how  repeaters  or  amplifiers  and  splitters  are 
employed  In  a  particular  Installation. 

Compared  to  star  topologies,  buses  use  considerably  less  cable  and  are 
much  more  reliable  and  flexible.  Compared  to  ring  topologies,  buses  are  more 
flexible,  offering  easier  expansion  and  adaptation  to  a  changing  environment.  Bus 
topologies  thus  have  significant  advantages  for  command  centers.  However,  ring 
networks  are  capable  of  supporting  high  data  rates,  priority  and  real /non-real 

a 

time  traffic. 

5.16.2  Transmission  [34] 

There  are  several  media  that  could  be  used  In  LAN's,  Including  twisted 
wire  pairs,  coaxial  cable,  optical  fiber,  free  space  (l.e.,  radio),  and  Infrared. 
The  decision  to  use  a  particular  medium  Is  usually  based  on  requirements 
concerning  bandwidth,  connectivity,  geographic  scope,  noise  Immunity,  security, 
cost,  and  suitability  for  the  application  at  hand.  Today,  radio  Is  both  expensive 
and  not  available  off-the-shelf;  Infrared  Is  expensive,  not  off-the-shelf,  and 
essentially  only  point-to-point;  twisted  pair,  while  Inexpensive,  Is  unsuitable 
with  respect  to  bandwidth  (except  with  multiple  twisted  wire  pairs  that  may  result 
In  space  utilization  problems),  noise  Immunity,  and  connectivity. 

Optical  fiber  has  the  potential  to  be  relatively  Inexpensive  when  the 
technology  matures;  currently  this  Is  expensive  and  just  becoming  easily 
available.  Optical  fiber  has  complete  noise  Immunity,  does  not  emanate,  and 
possesses  superior  bandwidth  capability.  Tapping  optical  fiber  is  difficult  - 
this  Is  a  plus  (from  a  security  point  of  view)  and  a  minus  (from  an  Installation 
point  of  view).  At  present,  only  baseband  transmission  techniques  have  been  fully 
developed  for  optical  fiber,  which  restricts  Its  use  to  a  single  Information 
channel. 
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Coaxial  cable  for  LAN's  nalces  use  of  established  cable  television 
technology,  which  accounts  for  Its  cost  advantages  and  easy  avail  ability  of 
components.  Other  characteristics  of  coaxial  cable  used  In  a  LAN  depend  on 
whether  baseband  or  broadband  signalling  Is  used. 

With  a  baseband  system,  an  attached  device  transmits  bidirectionally 
along  a  single  baseband  cable.  Broadband  systems  are  directional,  with  the 
Interface  unit  broadcasting  (on  a  "reverse"  channel)  to  the  "head-end."  The 
head-end  retransmits  the  signal  on  the  "forward"  channel  to  all  other  devices. 

Broadband  systems  may  use  either  single  or  dual  cables  for 
transmission.  A  mid-split  broadband  system  allows  the  Interface  unit  to  transmit 
and  receive  at  different  frequencies  on  the  same  cafcle.  This  Is  accomplished  by  a 
frequency  shift  at  the  central  retransmitter.  Dual  cables  allow  the  Interface 
unit  to  transmit  and  receive  at  the  same  frequency  on  different  trunks.  The  full 
bandwidth  of  the  cable,  typically  5  to  300  Megahertz  (or  400  MHz),  Is  available. 
Dual  cable  systems  use  unidirectional  amplifiers,  splitters,  and  taps; 
bidirectional  transmission  components  are  necessary  for  mid-split  systems. 
Balancing  of  signal  levels  throughout  the  network  Is  somewhat  more  complex  for  a 
mid-split  system. 

Compared  to  broadband,  baseband  signalling  currently  Is  capable  of 
somewhat  higher  data  rates,  and  the  Interface  units  are  less  expensive,  but  It  Is 
limited  to  a  single  Information  channel,  has  less  noise  Immunity  than  broadband 
systems,  and  can  span  distances  of  only  1  to  3  kilometers.  Broadband  systems 
support  topologies  spanning  10  or  more  kilometers  and  multiple  video,  voice,  and 
data  channels,  up  to  a  total  bandwidth  of  300  Megahertz  (or  more,  aependlng  on  the 
cable  type).  Broadband  signalling  Is  highly  dependent  on  modem  quality;  the 
modems  are  principally  responsible  for  the  current  cost  differential  compared  to 
baseband. 

In  summary,  broadband  cable  systems  appear  to  offer  significant 
advantages  for  command  center  LAN's.  These  advantages  Include  the  capability  to 
support  multiple  Information  channels  and  types  and  the  ability  to  cover  a  larger 
geographic  area  (than  baseband). 

5.16.3  Traffic  Effects  [34] 

Throughput  Requirements.  LAN  throughput  requirement  Is  a  function  of 
the  capacity  required  of  the  transmission  medium  plus  the  processing  capacity  at 
each  network  node.  A  quantitative  analysis  of  LAN  applications  Is  needed  to 
determine: 
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•  Message  sizes  (peak,  average,  and  variances) 

e  Responsiveness  characteristics 

e  Interval  between  messages  (peak,  average,  and  variances) 

Traffic  Classes.  It  Is  desirable  that  the  LAM  support  both 
connection-oriented  (stream)  and  connectionless  (datagram)  classes  of  traffic. 
Initially,  however,  most  LAM  applications  will  require  a  connection-oriented 
transport  service  such  as  the  Transmission  Control  Protocol  (TCP)  provides.  For 
example,  a  reliable  end-to-end  transport  service  Is  needed  for  applications  such 
as  file  transfers  to/from  a  local  word  processing  workstation  or  bulk  data 
transfers  between  cooperating  processes  residing  on  different  host  processors. 
Depending  upon  the  security  architecture,  transaction-oriented  traffic  such  as 
data  base  query  and  response  may  require  the  establishment  of  connections. 
Nondigital  (voice  and  video)  stream  traffic  also  requires  connection-oriented 
transport  services.  Connectionless  services  might  be  useful  for  such  applications 
as  the  LAN  accounting  functions. 

Tolerable  Network  Delay.  Another  LAN  parameter  Is  the  network-induced 
delay  that  can  be  tolerated  by  the  various  LAN  applications.  Requirements  can  be 
expressed  In  terms  of  absolute  delay  (maximum  allowable  delay  experienced  during 
transport)  and  delay  variance  (the  maximum  allowable  delay  variation  within  a  data 
stream). 

In  a  local  area  network  (as  opposed  to  a  long-haul  network),  most  of 
the  network-induced  delay  results  from  protocol  processing  (as  opposed  to 
transmission  delays).  Since  there  Is  a  tradeoff  between  reliability  (achieved  by 
error  detecting  and  correcting  protocols)  and  delay  (the  performance  penalty 
extracted  by  protocol  orocessing),  the  LAN  designer  should  note  that  the  command 
center  will  put  a  significant  processing  load  on  the  LAN  nodes  due  to  Its 
stringent  reliability  (and  also  security)  requirements.  Inadequate  processing 
power  within  the  LAN  nodes  will  lead  to  bottlenecks  within  the  LAN.  There  are 
tradeoffs  In  these  two  approaches  between  the  nodal  processing  resources  used  and 
the  transmission  bandwidth  resources  used. 

Interconnectivity  Between  Nodes.  Necessary  tools  for  the  LAN  design 
development  are  Intemoda)  data  flow  models  for  the  major  applications.  The 
models  must  Include  the  data  rates  (average  and  peak)  and  other  traffic 
characteristics  (such  as  stream  or  transaction  traffic).  These  now  models  are 
needed  to  determine  protocol  processing  capabilities  required  In  each  node  and  the 
adequacy  (e.g..  In  terms  of  connectivity  and  reliability)  of  various  LAN 
topologies. 


1 785D/LAN  5-118 


v.*/v,  >  y/.'.v. v’.v.v vv.-'.v.’-v- 


Within  the  security  constraints,  the  C2  LAN  will  provide  full 
(physical)  connectivity  between  all  nodes.  However,  the  local  system 
administrator  and  the  security  officer  need  the  capability  to  block  (logically) 
certain  connections  (for  example,  to  ease  the  burden  on  an  overloaded  host 
processor  or  In  response  to  a  security  violation). 

Concurrency  of  Connections.  Another  LAN  design  parameter  Is  the  degree 
of  concurrency  of  network  connections  that  terminate  at  a  given  node.  The 
communications  hardware  and  software  must  have  the  necessary  capacity  to  meet  the 
traffic  processing  requirements  of  the  applications  supported  by  the  node.  For 
example,  the  buffer  space  available  within  a  node  must  be  sufficient  for  all 
virtual  circuits  the  node  may  establish  during  a  period  of  maximum  connection 
concur-ancy.  Thus,  It  Is  important  In  the  LAN  design  to  establish  the  maximum  and 
average  number  of  concurrent  connections  at  each  node. 

Information  Transmission  Summary 

The  types  of  traffic  -  digital  data,  voice,  video,  and  Images  -  that 
may  be  transmitted  on  the  LAN  place  two  major  requl remei.ts  on  network  services: 

•  Transmission  rates  must  be  adequate  for  each  Information  type. 

•  Protocols  appropriate  to  each  Information  type  must  be  provided. 

Ulthout  a  broadband  local  area  network,  multiple  cable  will  be  required 

to  support  the  distribution  of  video,  voice,  and  digital  data.  As  a  point  of 
reference,  the  EIA  40.1  group,  In  conjunction  with  the  IEEE  802  Local  Area  Network 
committee.  Is  attempting  to  define  how  frequency  channels  on  a  broadband  LAN  might 
be  allocated.  Draft  C  of  the  IEEE  802  Local  Network  Standard  defined  thirty-four 
6  MHz  channels,  using  conventional  CATY  nomenclature  for  the  channel  numbers. 

Four  i  Mi/i  broadband  channels  would  be  allocated  to  one  6  MHz  channel;  5  Mb/s 
broadband  channels  would  use  one  6  MHz  channel;  a  10  Mb/s  broadband  channel  would 
use  two  adjacent  6  MHz  channels  (or  possibly  one  If  four  level, Vestigial  Sideband 
(VS8)  modulation  Is  used).  A  pairing  of  forward  and  reverse  channels  Is  also 
suggested  for  mid-split  single  trunk  configurations. 

5.16.4  Performance  Effects  of  LAN  Access  Methods 

The  literature  was  reviewed  to  obtain  results  of  previous  performance 
comparisons  done  for  LAN  media  access  protocols.  Sunroary  results  are  presented 
belcw  on  several  access  methods  and  the  IEEE  802  LAN  protocols. 


1785D/LAN 


5-119 


i 

i 


f 

4 


I 

* 

» 

* 

r 

r 

i 


i 


% 

> 

s 


5.16.4.1  Contention  Access  Techniques 

Report  £34]  provided  the  basis  for  the  following  results. 

ALOHA: 

This  w«s  originally  developed  for  satellite  packet  radio.  Messages  can 
be  transmitted  at  any  time.  A  random  timer  Is  started  when  a  message  Is 
transmitted;  If  It  Is  not  acknowledged  before  the  timer  runs  out.  It  Is 
retransml tted. 

Throughput  -  aoout  18  percent  of  circuit  capacity 

Stability  -  tends  to  become  unstable  causing  frame  delay  Increased  and 
throughput  decreased  at  loads  above  18  percent 

Slotted  ALOHA: 

A  modified  ALOHA  scheme  whereby  a  message  can  only  be  transmitted  at 
beginning  of  a  specified  time  slot. 

Throughput  -  about  36  percent  of  circuit  capacity 

Stability  -  also  tends  to  become  unstable  at  high  loads 

CSMA  and  CSMA/CD: 

Carrier  Sense  Multiple  Access  (CSMA)  requires  that  a  node  listen  to  a 
carrier  signal  before  transmitting.  If  another  ncde  Is  transmitting,  the  node 
will  either  back  off  for  a  specified  time  Interval  before  listening  again  or 
continuously  monitor  the  carrier  signal  until  the  network  Is  clear  to  send. 
Collision  Detection  (CD)  Is  a  mechanism  whereby  If  a  collision  occurs  during 
transmission,  both  sending  nodes  back  off  different  time  Intervals  (e.g.,  an 
exponential  back  off  algorithm)  and  try  again. 

Throughput  -  CSMA  Is  approximately  85  percent  for  small  networks; 
Increasing  propagation  delay  decreases  this  value  relative  to  the  data  frame 
length.  CSMA/CD  Increases  maximum  utilization  to  98  percent  of  the  circuit 
capacity.  Performance  decreases  with  decreasing  frame  size  and  Increasing 
propagation  delay  between  the  farthest  transmitters.  For  10  Mb/s  or  greater 
networks,  the  capacity  of  CSMA/CD  drops  to  66  percent. 

Stability  -  CSMA  does  exhibit  some  Instability  at  high  loads.  CSMA/CD 
exhibits  stability  under  extreme  overloads. 

5.16.4.2  Deterministic  Access  Techniques 

Report  [34]  provided  the  basis  for  the  following  results. 

Token  Passing: 

A  control  token  scheme  where  a  special  message  Is  passed  around  the 
network  and  the  node  with  the  token  Is  allowed  to  transmit. 
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Throughput  -  Depending  on  the  nodal  processing  delay,  the  capacity  of  a 
token  passing  network  approaches  98  percent.  Above  10  W>/$,  this  capacity  Is  not 
affected.  Large  size  networks  with  Uts  of  nodes  or  small  packets  may  Increase 
nodal  delays  significantly.  Transmission  delays  may  be  two  to  three  times  greater 
than  CSMA/CD  If  nodal  processing  delays  are  large. 

Stability  -  is  very  high. 

5.16.5  Comparing  Three  IEEE  802  LAN  Systems  Performance 

A  subcommittee  of  the  IEEE  802  has  prepared  a  report  [52]  on  expected 
performance  of  three  of  the  types  of  media  access  control  systems  specified  by  the 
IEEE  802  draft  standards.  That  report  indicates  that  the  CSMA/CD  systems  can  be 
expected  to  yield  the  shortest  delay  under  light  loading,  but  that  the  token  bus 
and  token  ring  systems  give  superior  performance  under  moderate  to  heavy  loads 
(see  Subsequent  Discussions). 

In  their  analysis,  th:  subcommittee  did  not  consider  the  built-in 
priority  fu.Ktions  of  the  token  bus  and  tcken  ring  systems,  since  they  were  not 
yet  defined.  In  light  of  this  added  capability,  the  token  bus  and  token  ring 
local  network  systems  must  be  considered  superior  to  the  CSMA/CD  systems  fcr  those 
applications  where  data  of  different  priority  must  be  transmitted  across  the  same 
local  network. 

Because  medium  access  and  logical  link  LSI  devices  are  now  becoming 
available  for  CSMA/CD  systems,  these  will  be  the  dominant  form  of  commercial 
shared  medium  local  networks  during  the  next  few  years.  LSI  devices  for  token 
ring  and  token  bus  access  will  be  available  In  the  next  1-2  years. 

Token  bus  baseband  and  broadband  systems  seem  to  be  the  choice  of  the 
Industrial  automation  users,  based  upon  the  work  of  the  U.S.  Process  Data  Highway 
Committee  (PROWAY)  of  the  International  Electrotechnical  Commission  (IEC)  standard 
body.  Subcommittee  65,  Working  Group  6  of  the  IEC  Is  presently  extending  the  IEEE 
802  token  bus  draft  standard  for  use  In  Industrial  environments. 

Token  ring  baseband  systems  have  been  chosen  by  IBM  and  several  other 
major  computer  manufacturers  as  their  preferred  LAN  because  of  the  token  ring 
multi  priority  level  capability,  because  the  token  ring  provides  a  deterministic, 
rather  than  statistical,  access  time,  and  because  as  data  rates  Increase,  the 
required  dead  time  between  transmissions  on  a  LAN  ring  Is  shorter  than  that 
requ'red  for  comparable  bus  topologies. 
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5.16.5.1  Detailed  Comparisons  [52] 

A  highlight  of  the  IEEE  802  draft  report  of  the  subcommittee  Is  a 
numerical  comparison  for  the  different  media  access  methods  with  a  fixed  common 
message  transmission  load.  Two  workloads  were  used  to  bound  performance:  In 
Figures  5.16.5.1-1  through  5.16.5 .1 -3,  one  station  out  of  100  Is  always  actively 
transmitting  a  message  and  message  size  Is  varied:  500,  1000  and  2000  bits.  In 
Figures  5.16.5.1-4  through  5.16.5.1-6,  100  out  of  100  stations  are  active  with 
message  transmission.  The  horizontal  axis  or  abscissa  as  in  either  case  is  the 
raw  data  transmission  speed  of  the  network  (the  clock  rate),  while  the  vertical 
axis  or  ordinate  Is  the  actual  carried  data  rate,  the  rate  at  which  data  bits  are 
successfully  transmitted.  The  ideal  case  Is  to  use  zero  transmission  capacity  for 
network  access  control,  which  would  be  a  straight  line  with  slope  unity*  The 
deviation  from  this  straight  line  shows  the  penalty  paid  using  the  same  network  to 
control  access  as  well  as  transmit  messages. 

Figure  5.16.5.1-7  Is  a  plot  of  lower  bound  on  message  delay  versus 
nimber  of  active  stations,  assuming  each  station  goes  Idle  for  a  mean  amount  of 
time  Tjd*e  and  then  active  in  order  to  transmit  a  message. 

The  best  avail all e  evidence  today  Is: 

•  Token  passing  via  a  ring  Is  the  least  sensitive  to  workload  and 
offers  short  delay  under  light  load  and  controlled  delay  under 
heavy  load. 

e  Token  passing  via  a  bus  has  the  greatest  delay  under  light  load  and 
under  heavy  load  cannot  carry  as  much  traffic  as  a  ring  and  Is 
quite  sensitive  to  the  bus  length  (through  the  propagation  time  for 
ene*^y  to  traverse  the  bus).  _ 

•  Carrier  sense  collision  detection  offers  the  shortest  delay  under 
light  load,  while  It  Is  quite  sensitive  under  heavy  load  to  the 
workload  and  Is  sensitive  to  the  bus  length  (the  shorter  the  bus 
the  better  It  performs)  and  to  message  length  (the  longer  the 
packet  the  better  It  does). 

a  Reservation  access  via  a  bus  Is  the  least  understood  of  all  access 
methods,  yet  may  offer  the  simplicity  of  access  under  light  load  of 
carrier  sense  collision  detection,  and  the  controlled  access  under 
heavy  loading  of  token  passing. 

5.16.5.2  Delay  VRS  Throughput  for  IANS 

This  provides  comparison  of  CSHA/CD  and  token  ring  delay  versus 
throughput  characteristics.  Report  [53]  provided  the  basis  for  the  results  given. 
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Figure  5.16.5.1-1.  Maximum  Mean  Carried  Data  Rate  Versus  Actual 
Transmission  Rate  (500  Bit  Packet  and  One  Active  Station) 
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Figure  5.16.5.1-2.  Maximum  Mean  Carried  Data  Rate  Versus  Actual 
Transmission  Rate  (1000  Bit  Packet  and  One  Active  Station) 
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Figure  5.16.5.1-4.  Maximum  Mean  Carried  Data  Rate  Versus  Actual 
Transmission  Rate  (500  Bit  Packet  and  100  Active  Stations) 
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Figure  5.16.5.1-5.  Maximum  Mean  Carried  Data  Rate  Versus  Actual 
Transmission  Rate  (1000  Bit  Packet  and  100  Active  Stations) 
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Figure  5.16,5.1-7.  Mean  Packet  Delay  Versus  Number  of  Active  Stations 
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TWo  performance  aspects  are  of  primary  Interest:  the  del  ay- throughput 
characteristic  of  the  nedla-access  control  schemes,  and  system  behavior  when  the 
load  approaches  the  saturation  point.  There  exists  a  Targe  body  of  performance 
analyses  of  ring  and  bus  systems.  Some  examples  are  given  In  [54,  55,  56].  In 
the  following,  use  Is  made  of  some  of  the  results  reported  In  [57].  Figures 
5.16.5.2-1  through  5.16.5.2-3  [54,  55,  56]  show  the  delay-throughput  relation  of 
token  ring  and  CSKA/ CO  bus  for  two  data  rates:  1  Kb/s  and  10  Mb/s. 

The  general  conclusions  we  can  draw  from  these  results  are:  1)  at  a 
data  rate  of  1  Mb/s,  both  systems  perform  equally  well;  2)  If  the  data  rate  Is 
Increased  to  10  Mb/s,  the  token  ring  has  better  performance  characteristics  over  a 
wide  range  of  parameters.  In  Figure  5.16.5.2-1,  the  frame-length  distribution  Is 
negative  exponential  with  an  average  value  of  1,000  bits.  A  frame  represents  the 
entity  transmitted  by  a  station  when  It  has  access  to  the  medium.  The  critical 
parameter  that  determines  the  performance  of  the  CSMA/CD  bus  Is  the  ratio  of 
propagation  delay  to  mean  frame  transmission  time.  Since  the  propagation  delay  Is 
Independent  of  the  data  rate,  this  ratio  Increases  with  the  data  rate.  Theory 
shows  [56]  that  a  CSMA/C0  bus  behaves  Ideally  as  long  as  this  ratio  Is  sufficiently 
low.  If,  for  reasonable  traffic  loads.  It  exceeds  2-5  percent,  the  Increasing 
collision  frequency  will  cause  significant  performance  degradation. 

If  on  a  CSMA/CD  bus,  collision  occurs,  transmission  will  be  aborted, 
and  the  station  will  reschedule  its  frame  by  selecting  a  random  retransmission 
Interval,  the  length  of  which  Is  dynamically  adjusted  to  the  actual  traffic  load 
to  avoid  an  accumulation  of  retransmissions.  The  high  collision  frequency  at  high 
load  levels  together  with  the  retransmission  policy  causes  the  variation  of  the 
transfer  delay  to  grow.  The  practical  consequence  Is  the  danger  of  stations 
becoming  locked-out  for  an  unpredictable  period  of  time.  A  token  ring,  on  the 
other  hand,  guarantees  fair  bandwidth  sharing  among  all  active  stations  even  at 
high  load  levels  because  the  token  has  to  be  relinquished  after  the  transmission 
of  one  frame. 

The  general  validity  of  the  conclusions  drawn  above  Is  supported  by 
Figures  5.16.5.2-2  and  5.16.5.2-3.  In  Figure  5.16.5.2-2,  all  parameters  are  the 
same  as  before  except  for  the  length  of  the  cable,  which  Is  now  10  km  Instead  of 
2  km.  The  curve  for  the  CSMA/C!)  bus  at  10  Mb/s  Illustrates  the  Impact  of  the 
propagation  delay,  and  confirms  the  Importance  of  the  ratio  propagation  delay  and 
average  frame  transmission  time.  As  a  practical  consequence,  all  CSMA/CD  systems 
being  discussed  specify  a  maximum  distance  which  is  less  than  10  km.  Finally, 
Figure  5.16.5.2-3  further  demonstrates  the  robustness  of  the  results.  There,  the 
frame-length  distribution  has  a  coefficient  of  variation  of  2. 
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Del  ay -Throughput  Characteristics 
for  Token  Ring  and  CSMA/CD  Bus 
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Figure  5.16.5.2-1. 
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Figure  5.16.5.2-2. 
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Figure  5.16.5.2-3. 
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5.17  Evaluation  cf  TCP/7P  In  a  Local , Network  Environment 
5.17.1  Performance  Results 

Review  was  made  of  experiments  previously  conducted  by  MITRE  on  TCP/IP 
In  a  IAN  environment.  Reports  [45,  46,  47,  48]  were  used  as  the  basis  for  the 
findings  reported  here. 

It  was  considered  essential  In  reference  [45]  for  the  program-to- 
program  communication  performance  of  a  LAN-based  command  ctnter  to  be  comparable 
to  the  process-to-process  speeds  found  In  existing  mainframe  hosts.  Evaluations 
of  a  prototype  network,  using  a  media  signalling  rate  of  890  kb/s  was  made  [45, 
46],  (The  890  kb/s  rate  was  limited  by  the  peripheral  Interface  chips  used.) 
Employing  512  byte  data  messages  resulted  In  a  348.9  kb/s  rate  between  TCP  users. 
It  was  noted  in  the  report  "that  this  rate  Is  almost  10  times  greater  than  any 
previous  TCP  Implementation."  Fine  tuning  of  TCP  retransmission  and 
acknowledegment  policies  were  modified  more  than  any  other  to  achieve  these 
results. 

Subsequent  to  the  above  reporting  on  TCP  performance,  reference  [47] 
reported  another  set  of  results.  This  involved  using  a  10  Mb/s  Ethernet  CSMA/CD 
configuration  on  a  68000  board  containing  TCP/IP.  At  a  10  Mb/s  media  signalling 
rate,  and  a  4  millisecond  packet  processing  time  limiting  factor  (caused  by  the 
processor  on  the  Ethernet  board),  an  effective  transfer  rate  from  source  to  sink 
of  892  kb/s  was  achieved.  It  was  concluded  that  performance  of  TCP/IP  was  good, 
the  number  of  bytes  of  overhead  was  not  an  Important  Issue,  that  TCP/IP  had 
built-in  security  features  and  that  1  Mb/s  throughput  would  be  achievable  with  the 
right  hardware. 

Another  MITRE  Investigation  [45,  48]  considered  the  possibilities  of 
subsetting  TCP/IP  when  used  for  Intra-LAN  traffic  exchanges.  A  "discretionary" 
set  of  TCP/IP  transport  protocols  was  considered.  It  was  reported  that  "they 
provide  a  flexible  means  of  using  IP  and  TCP  for  high  bandwldths,  low  delay 
environments  and  at  the  same  time  preserve  the  ability  to  gracefully,  via  a  local 
long  haul  gateway  translator.  Interact  with  computers  located  or.  a  long  haul 
network." 

This  approach  was  based  upon  making  IP  and  TCP  mechanisms  not  needed  in 
an  Intra-LAN  operation  as  options,  but  that  all  options  had  to  be  Implemented. 

This  meant  that  all  LAN  implementations  need  contain  all  the  capabilities  of  the 
standard  long  haul  versions,  but  the  full  range  of  capabilities  was  not 
necessarily  Invoked  for  every  intra-LAN  packet  of  data. 
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It  is  believed  [45,  48]  that  significant  savings  In  protocol  header 
overhead  and  software  processing  can  be  obtained  with  the  use  of  the 
"discretionary  TCP/IP"  and  that  this  protocol  Interworks  with  standard  TCP/IP 
networks  with  a  simple  translation  at  a  gateway  between  the  local  and  other 
network,  thereby  fulfilling  all  the  »equ1rements  of  a  local  network  protocol. 

The  MITRE  work  [45,  48]  also  considered  the  use  of  error  checksum  In 
the  TCP  and  IP  packet  header  for  Intra-LAN  traffic.  It  was  concluded  that  the 
software-based  TCP/IP  checksum  processing  delays  and  error  protection  provided 
were  not  justified  when  employed  with  more  powerful,  better  performing  and 
hardware  implemented  ones  In  the  basic  underlying  LAN  transmission  protocols. 

Where  TCP/IP  packets  would  traverse  into  the  long  haul  networks,  the  standard 
TCP/IP  checksums  should  then  be  invoked  to  provide  end-to-end  protections. 

Overall,  MITRE  concluded  that  the  "discretionary"  version  of  TCP  and  IP 
did  not  offer  commanding  advantages  but  did  recommend  to  include  them  in  any 
forthcoming  reviews  of  the  TCP  and  IP  standards.  Further,  that  while  the 
discretionary  versions  do  reduce  header  overhead  and  cause  no  perturbation  to  the 
basic  TCP  and  IP  operations,  this  was  considered  as  being  short-sighted:  a  school 
of  thought  which  considers  making  protocol  selections  based  solely  on  header 
overhead  and  communication  line  utilization. 

5.17.2  Simulation/Modeling  of  TCP/IP/Ethernec  LAN 

This  subsection  discusses  effort  on  the  LAN  Study  which  was  devoted 
towavds  development  of  a  simulation/modeling  capability  for  use  in  evaluating 
LAN-basea  networking  protocols  and  the  results  obtained.  The  motivation  for  this 
was  the  recognition  of  the  complexity  involved  in  performance  assessing  multiple 
layers  of  protocols  when  configured  in  both  the  intra  and  inter-LAN  topologies. 

An  introduction  is  given,  discussing  the  modeling  objectives,  followed  by  a 
description  of  the  design  approach.  Results  obtained  to  date  are  g*ven.  A 
detailed  description  of  the  simulation/modeling  design  is  contained  in  [95], 
titled  "Progressive  Project  Document  -  Local  Arc»  Network  Inter  Operability  Study 
Simulation." 

5.17.2.1  Objectives 

A  paper  published  by  Didlc  and  Wol finger  [58]  formed  the  basis  of  the 
architectural  approach  to  representing  a  LAN-based  suite  of  protocols  for 
networking.  Of  particular  interest  was  the  methodology  employed  by  Didlc  and 
Wol finger  in  representing  the  OSI  layered  protocol  model  and  accounting  for  use  of 
internal  computer  resources  to  implement  the  protocol-functions.  Their  paper  was 
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vhe  first  Identified  to  attempt  to  follow  the  OSI  model  so  closely.  In  their 
paper  [58],  the  following  points  were  made,  which  the  LAM  Study  found  particularly 
relevant  to  the  Investigation  being  conducted:  j 

"One  of  the  areas  requiring  the  use  of  simulation  models  is  the  | 

integrated  analysis  of  a  hierarchy  of  communication  protocols."  j 

"In  our  opinion,  designers  of  simulation  systems  should  pursue  as  a 
final  goal  a  modeling  tool  wnlch  comprises  components  comparable  to  those  oefined 
by  the  ISO  Reference  Model.  It  should  enable  Its  user  to  tailor  his  simulation  ‘ 

system  by  configuring  network  nodes,  layers,  protocols  and  their  attributes."  j 

Our  overall  objective  In  the  LAN  Study  has  been  to  develop  an 
architectural  model  for  a  LAN-based  computer  network  Initially  and  later  to  expand 

f 

this  Into  an  Internet  of  Interconnected  LAN's,  using  representations  of  wide  area  < 

net  effects.  It  was  felt  the  model  should  allow  the  following:  | 

-  Description  of  communication  protocols  ‘ 

Allocation  of  resources  within  the  communicating  computers  l 

-  Generation  of  requests  (workload)  created  In  a  real  system  by  the  *' 

users  of  the  network  | 

Simulation  RXJdeling  is  a  recognized  technique  for  the  analysis  of  " 

complex  systems.  8y  constructing  a  model  1 ncorporatl ng  system  characteristics  and 
reproducing  Its  behavior  over  time,  system  performance  under  various  conditions 
can  be  assessed.  Since  a  simulation  model  captures  the  time-dependent  aspects  of  -m 

both  system  functions  and  loading,  complex  total  system  behavior  can  be  studied. 

A  discrete  event  simulation  model  was  developed  to  assess  the 
performance  of  Integrated  layered  protocols  In  a  local  area  network  environment.  [. 

The  performance  was  quantitatively  evaluated  during  experimentation  by  the  i; 

collection  of  these  statistics  for  each  protocol  and  for  the  entire  network:  £ 

e  Throughput  !* 

t  Delay  time  / 

•  Queue  lengths 

•  Retransmissions  f 

turn 

9  Resource  utilization 

Another  objective  was  to  provide  maximum  flexibility  In  the  .v 


configuration  of  experiments.  The  user  was  permitted  to  select  which  protocols  K; 

were  to  be  modeled  as  well  as  to  specify  the  following  parameters: 

km 

9  Protocol  parameters,  i.e.,  processing  times  and  header  sizes  r; 

9  System  configuration,  i.e.,  number  of  nodes  and  rate  of  channel  > 

t  Traffic  characteristics,  I.e.,  message  lengths  and  arrival  rates 
•  Node  processor  characters  tics,  I.e.,  speed  and  other  loading  j.' 


L, 

1 785D/LAri  5-134  !$ 


5.17.2.2  Simulation  Approach 

A  simulation  model  1$  an  abstraction  of  the  actual  system  It 
represents.  It  does  not  propose  to  be  an  exact  replica  where  every  minute  detail 
Is  emulated.  However,  the  time-critical  aspects  of  the  system  can  be  modeled  In 
great  detail.  The  task  of  modeling  Involves  the  Identification  of  system  features 
relevant  to  the  study  goals  and  characterizing  them  In  sufficient  detail  to  meet 
these  goals.  A  model,  therefore,  represents  the  relevant  aspects  of  the  system 
and  stuales  the  behavior  of  the  system  over  time  with  respect  to  these  factors. 

5.17.2.3  Simulation  Methodology 

The  first  step  In  using  simulation  techniques  to  accomplish  the  goals 
of  a  modeling  effort  Is  to  specify  the  requirements.  During  frequent  user/analyst 
meetings  It  was  determined  that  the  requirements  were: 

•  To  allow  the  variation  of  protocol  parameters  and  configuration. 

e  To  simulate  loading  on  the  channel  during  a  simulation  experiment 

In  order  to  provide  realistic  contention  and  utilization  of  the 
charnel . 

•  To  model  In  detail  the  processing  required  to  handle  the  selected 
protocols  as  well  as  representing  the  other  processing  required  to 
handle  user  applications.  The  simulation  of  processing  required 
for  protocols  had  to  Include  task  generators  and  protocol  submodels 
for  a  variety  of  media-access  and  host-to-host  protocols. 

•  To  accumulate  throughput,  delay  and  queue  statistics  and  report  the 
.esults. 

The  second  step  Involves  designing  a  model  which  represents  the  system 
under  study  and  provides  the  detail  necessary  to  satisfy  the  objectives.  The 
design  was  documented  In  a  simulation-oriented  pseudo  code  and  was  reviewed  to 
assure  Its  accuracy.  The  areas  where  It  was  decided  that  great  detail  would  be 
used  were  the  contention  for  the  channel  In  the  Ethernet  protocol  and  the  TCP 
protocol  handshakes  and  state  changes. 

The  model  structure  Is  described  1  r.  the  overview  provldea  In  the  next 
paragraph  section. 

The  third  step  Is  to  convert  the  design  to  computer  executable  code. 

The  model  was  Implemented  In  SLAM  II. 5  (Simulation  Language  for  Alternative 
Modeling)  and  the  user  Interface  was  coded  In  FORTRAN  77.  SLAM  provided  the  high 
level  simulation  language  constructs  useful  for  the  model  while  FORTRAN  provided 
the  capability  to  have  an  interactive  user  interface. 
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The  aodel  was  Impleuented  In  a  top-down  fashion  with  great  care  taken 
that  the  framework  be  very  modular  to  allow  the  later  addition  of  other  protocols 
and  layers.  Also,  the  model  was  very  parameterized  to  provide  the  user  great 
flexibility  in  configuring  the  system  for  an  experiment. 

The  fourth  step  is  to  verify  and  validate  the  model.  Verification  Is 
the  process  of  determining  that  a  model  executes  as  Intended.  Techniques  used  for 
verification  included  traces,  examination  of  the  summary  report,  and  structured 
walkthroughs. 

Each  protocol  submodel  was  first  tested  with  only  one  message  entity, 
then  with  multiple  entities.  Each  submodel  was  also  tested  separately  before 
being  combined  and  tested  with  other  submodels. 

Event  traces  were  used  to  verify  each  submodel.  They  provided  a  step 
by  step  report  of  the  location  of  an  entity  and  the  simulated  time  at  every  point 
in  the  program  where  simulated  time  passes.  The  various  conditions  to  be  tested 
were  forced  in  order  to  trace  that  entitles  followed  the  correct  routes  through 
the  network,  that  the  correct  amount  of  simulated  time  passed,  and  that  entities 
had  the  correct  attributes. 

The  sunnary  report  also  provided  other  data  used  in  debugging  the 
program.  Data  was  provided  on  the  minimum,  maximum,  and  current  status  of 
resources,  files,  and  activities.  Additional  debugging  information  was  available 
from  the  statistics  collected  on  collisions,  retrys,  Interarrival  times,  message 
lengths,  time  in  layers  and  contents  of  the  TCP  Transmission  Control  Block. 

A  structured  walkthrough  at  which  several  programners  stepped  through 
the  Implementation  and  evaluated  the  flow  of  logic  was  used  to  verify  all 
submodels. 

Validation  is  the  process  of  determining  that  the  model  is  an  accurate 
representation  of  the  actual  system.  The  validation  techniques  used  were  hand 
calculations,  comparison  with  published  results  and  face  validity  checks  with 
experts. 

For  example,  the  expected  performance  of  the  model  could  be  hand 
calculated  for  the  case  where  only  one  node  is  transmitting.  The  performance  of 
the  model  was  also  compared  to  published  results  from  other  studies.  The  Ethernet 
submodel,  for  example,  was  compared  with  results  released  by  the  IEEE  Project  802 
Traffic  Handling  Characteristics  Committee  Report  [52]  and  the  TCP  submodel  was 
tuned  to  results  reported  by  MITRE  [45-48]. 

The  fifth  step  was  experimentation  with  the  model.  T’iis  Involved  the 
collection  of  data  from  many  simulation  model  executions.  This  process  is 
documented  In  Paragraph  5.17.2,5. 
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5.17.2.4  simulation  Model  Structure 

The  LAN  Interoperability  Study  simulation  provides  LAN  model 
configuration,  simulation,  and  reporting  of  statistics. 

The  subdivisions  of  the  software  are: 

•  Setup 

The  Setup  submodel  Interfaces  with  the  user  to  allow  selection  of 
network  configuration,  loading  and  protocols  configuration. 

•  Model 

The  Generators  submodels  generate  requests  for  the  highest  layer 
protocol  being  simulated.  This  models  the  requests  from  the  client 
above  the  highest  layer  protocol  In  the  nodes  modeled  In  detail. 

The  Ethernet  Generator  submodel  also  may  be  used  to  generate 
loading  on  the  channel  to  represent  contention  caused  by  nodes  not 
modeled  In  detail. 

The  Protocol s  submodels  simulate  the  passage  of  messages  down 
through  the  protocol  layers,  across  the  channel,  and  back  up  the 
layers  to  the  client. 

•  Reports 

The  Reports  submodel  produces  a  summary  of  the  statistics  collected 
In  the  other  submodels. 

Figure  5.17.2.4-1  Illustrates  the  division  of  the  software  Into 
submodels.  A  Control  Flow  diagram  is  shown  In  Figure  5.17.2.4-2. 
a.  Setup 

The  Setup  submodel  Interfaces  with  the  user  to  allow  selection  of 
network  configuration  parameters  and  node  configuration 
parameters.  The  Setup  submodel  Is  divided  Into  several  modules: 

•  Exec 

The  Exec  submodel  Interfaces  witn  the  user  via  menu  to  allow 
selection  of  the  secondary  menus  listed  below  and  also  forces  the 
user  to  specify  which  protocols  are  to  be  modeled, 
a  General  Setup 

The  General  submodel  interfaces  with  the  user  to  allow 
selection  of  the  simulation  run  time  and  node  configuration 
parameters  for  six  types  of  nodes.  These  parameters  Include 
the  arrival  rate  and  length  of  messages  as  well  as  processor 
and  TCP  connection  characteristics. 
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•  Ethernet  Setup 

The  Ethernet  Setup  submodel  Interfaces  with  the  user  to  allow 
selection  of  Ethernet  parameters  such  as  channel  rate,  number 
of  jam  bits,  one-way  propagation  time,  encapsulation  time,  and 
hardware  interface  to  the  host  processor. 

•  LLC  Setup 

The  LLC  Setup  submodel  interfaces  with  the  user  to  allow  the 
selection  of  the  logical  link  control  parameter  for  processing 
time. 

•  IP  Setup 

The  IP  Setup  submodel  interfaces  with  the  user  to  allow  the 
selection  of  the  internet  protocol  parameter  for  processing 
ti  me . 

•  TCP  Setup 

The  TCP  Setup  submodel  interfaces  with  the  user  to  allow  the 
selection  of  the  transmission  control  protocol  parameters  such 
as  timeout  period,  time  to  process  each  state  change,  and 
transmission  failure  loss  probability. 

•  UP.P  Setup 

The  UDP  Setup  submodel  interfaces  with  the  user  to  allow  the 
selection  of  the  user  datagram  protocol  parameters  for 
processing  time  and  quantity  of  earh  type  of  node, 
b.  Model 

The  Model  submodels  represent  the  arrival  of  requests  for  message 
transmission  from  the  client  layer  and  represent  the  processing 
required  by  each  protocol  selected.  The  model  Is  subdivided  into 
these  suomodels: 

•  Generators 

The  Generator  submodels  create  entities  to  be  passed  to  the 
protocol  submodels.  The  generators  represent  the  client  layer 
above  the  highost  protocol  layer  being  modeled  and  loading  at 
the  media-access  level. 

•  Protocols 

The  Protocol  submodels  simulate  the  operations  of  the  selected 
protocols.  Message  entities  are  passed  from  one  protocol 
submodel  to  another  as  specified  In  Setup.  Figure  5.17.2.4-3 
shows  the  protocol  submodels  currently  Implemented. 
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Figure  5.17.2.4-3.  Implemented  Protocols  Diagram 

5.17,2.5  Results  -  Simulation  Experiments 

The  model  Mas  designed  and  implemented  to  be  very  parameterized  so  that 
many  experiments  could  be  easily  configured  to  study  The  effects  of  varying 
specific  parameters.  The  results  of  these  experiments  are  summarized  in  the 
following  pages. 

The  protocols  of  greatest  Interest  during  this  study  were  Ethernet  and 
TCP.  They  w ere  modeled  In  more  detail  and  more  experimentation  was  done  to 
determine  their  performance  than  with  the  ether  protocols  as  resources  to  be 
devoted  to  this  were  constrained  to  a  subset  of  the  overall  objectives  set  out  at 
the  start  of  the  study. 

5.17.2.5.1  Ethernet  Experimentation  Results 

The  performance  characteristics  of  interest  for  the  Ethernet  protocol 
were  throughput,  one-way  delay,  and  number  of  collisions  as  a  function  of  channel 
(medium)  loading  utilization,  number  of  nodes  transmitting  and  message  length. 

The  results  obtained  are  given  in  Figures  5.17.2.5.1-1  through  5.17.2.5.1-4. 

In  all  the  Ethernet  experimentation,  the  model  was  configured  per  the 
following  Ethernet  blue  book  parameters  [96]: 


Number  of  jam  bits 

32 

Number  of  preamble  bits 

64 

Number  of  framing  bits 

144 

Interframe  delay  time 

9.6  microseconds 

Backoff  slot  time 

51.2  microseconds 

Channel  rate  per  second 

10  megabits 
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The  following  estimated  processing  times  were  used: 

Transmit  encapsulation  time  500  microseconds 

Receive  decapsulation  time  1000  microseconds 

Figure  5.17.2.4-3  shows  the  Ethernet  portion  In  relation  to  the  higher 
layer  protocols  (LLC,  IP,  TCP,  UDP).  The  results  obtained  for  the  Ethernet  wore 
done  alone,  without  any  higher  layer  protocols  implemented.  Instead,  they  were 
represented  as  "client" 'loadings  and  presentea  traffic  to  Ethernet  to  process.  In 
the  figures  which  give  the  results  (Figures  5.17.2.6.1-1  through  5.17.2.5.1-4), 
Ethernet  All  Data  refers  to  total  traffic  on  the  cable  medium,  Ethernet  Client 
Data  refers  to  external  representation  of  the  higher  layer  protocols,  message 
lengths  are  in  bits  and  the  nodes  which  loaded  the  cable  medium  were  simulated  by 
traffic  generators. 

Ethernet  All  Data  Throughput  (Figure  5.17.2.5.1-1) 

Several  simulation  runs  were  made  where  four  different  sized  ci.ent 
data  packets  were  utilized  (500,  1000,  2000  and  4000  bits  per  packet)  while 
loading  on  the  cable  (medium)  was  increased  at  discrete  amounts  (1,  10,  50  and  100 
nodes).  Each  node  was  caused  to  always  have  client  data  for  transmission.  As  a 
result,  this  causea  collisions  on  the  cable  to  Increase  as  more  and  more  nodes 
were  added.  The  results  demonstrated  two  properties,  as  follows: 

1.  Total  potential  cable  throughput  decreased  as  a  function  of 
increasing  nodes  (collisions)  on  the  cable 

2.  Increased  sized  packets  yielded  better  throughput  performance  (less 
cable  accessing  occurs  with  larger  sized  packets) 

As  the  number  of  nodes  was  varied  from  1  to  100,  the  cable  throughput  potential 
was  reduced  by  more  than  50  percent  (for  1000  bit  packet  size  this  changed  from 
approximately  9  down  to  3  Mb/s).  Therefore,  while  a  IQ-Mb/s  Ethernet  cable  system 
might  be  being  employed,  the  actual  potential  system  throughput  at  the  cable  is 
very  sensitive  and  Is  determined  by  the  total  demand  for  bandwidth  from  those 
nodes  attached. 

Ethernet  Client  Data  Throughput  (Figure  5.17.2.5.1-2) 

This  shows  the  corresponding  throughput  values  that  were  achieved  at 
the  client  interface  to  Ethernet  (client  is  the  representation  of  Ethernet's 
higher  layers).  The  results  were  the  same  as  that  which  occurred  at  the  cable 
(medium)  except  for  a  decrease  In  throughput  overall  caused  by  the  Ethernet 
overhead.  Therefore,  the  client  throughput  values  are  less  than  the  All  Data 
values. 
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Figure  5.17.2.5.1-1.  Ethernet  All  Data  Throughput 


1 787D/LAN 


5-142 


NO.  NODES  TRANSMITTING 


UTS/PACKET 

BITS/PACKET 

BITS/PACKET 

BITS/PACXET 


Figure  5.17.2.5.1-2.  Ethernet  Client  Data  Throughput 
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Figure  5.17,2.5.1-4.  Ethernet  One-Way  Delay 
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Ethernet  Collisions  (Figure  5.17.2.5.1-3) 

While  simulation  runs  were  being  made  data  was  collected  on  the  number 
of  total  Ethernet  collisions  which  occurred  at  the  cable  level.  The  figure  shows 
this  for  the  case  of  10  and  100  nodes  as  a  function  of  %  channel  utilization  of 
the  potential  10  Mb/s  capacity.  The  results  indicated  that  collisions  Increased 
almost  linearly  as  the  loading  or  the  cable  Increased  for  the  10-node  case,  but 
not  as  linear  tor  the  100-ncde  case.  This  difference  was  believed  caused  by  the 
different  run  lengths  In  time  that  were  employed.  Further,  the  Ethernet 
collisions  seemed  to  be  Independent  of  the  number  of  nodes  actively  Impressing  the 
loading  on  the  channel.  The  Increase  in  channel  utilization  was  seen  to  be  the 
major  contribution  to  throughput  reduction  seen  In  the  previous  figures  and 
produced  the  decrease  as  the  number  of  collisions  which  occurred  Increased. 

Ethernet  One-Way  Delay  (Figure  5.17.2.5.1-4) 

For  some  applications,  one-way  delay  Is  a  more  critical  performance 
criteria  than  Is  throughput.  Measurements  were  made  of  Ethernet.  Results  were 
obtained  for  the  average  and  maximum  one-way  delays  from  source  Ethernet  Hlent  to 
destination  Ethernet  Client. 

The  results  show  that  average  delay  remained  nearly  constant  across  the 
channel  loadings  employed  but  that  maximum  delay  exhibited  a  much  more  severe 
degradation  as  60-65  percent  was  Incurred  In  loading.  This  follows  tne 
theoretical  prediction  of  delay-throughput  tor  CSMA/CD  systems. 

The  throughput  and  one-way  delay  values  shown  on  these  graphs  are  the 
maximum  values  achieved  In  a  finite  number  of  runs  In  which  the  Interarrival  rates 
of  messages  were  varied. 

5.17.2.5.2  TCP  and  IP  Experimentation  Results 

The  performance  characteristics  of  Interest  for  the  TCP  protocol  were 
throughput,  one-way  delay,  and  maximum  queue  length  as  a  function  of  Input  rate, 
CPU  speed  factor,  and  channel  utilization- 

For  the  TCP  experimentation  the  processing  times  were  configured  as 
follows.  These  numbers  were  derived  from  statistics  published  by  MITRE  [45-48]  on 
the  time  for  TCP  to  process  data.  Other  processing  times  were  estimated  from 
MITRE  furnished  design  data  for  TCP  by  comparison  of  number  of  lines  and 
complexity  of  code  with  the  process  data  time.  These  comparisons  were  made  using 
a  C  programming  language  implementation  of  TCP. 
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Attach  header  processing  time 

0.015  ms 

Deliver  data  processing  time 

9.0  ms 

Active  open  processing  time 

5.4  ms 

CRC  compute  time  per  bit 

0.23  ms 

Send  data  processing  time 

5.9  ms 

Close  response  processing  time 

3.8  ms 

Close  processing  time 

1.1  ms 

Close  success  processing  time 

5.6  ms 

Open  response  processing  time 

5.6  ms 

LLI  receive  processing  time 

U.G1  ms 

Open  success  processing  time 

4.7  ms 

ULI  receive  processing  time 

9.0  ms 

Establish  processing  time 

3.2  ms 

TCP  receive  processing  time 

0.01  ms 

For  IP  the  following  values  were 

used: 

IP  Send 

2.5  ms 

IP  Receive 

2.5  ms 

A  value  of  2  ms  was 

used  for  the 

IP  to  Ethernet  Interface  Time. 

Input  Versus  Throughput  Rate  for 

Single  TCP  Connection-Single  Mode 

(Figures  5.17.2.5.2- 

■1  and  5.17.2.6.2-2) 

TCP  anu  IP  protocol  processing  times  were  added  onto  the  previously 
discussed  Ethernet  models.  Most  of  the  TCP  protocol  functions  were  represented, 
except  for  the  flow  control  and  window  management  operations  (there  was  not  enough 
time  to  investigate  their  effects).  The  objective  was  to  determine  the  potential 
best  performance  obtainable  in  a  LAM  environment  and  sensitivities  to  different 
representations  of  Internal  machine  processing  speeds.  At  the  CPU  speed  factor 
given,  protocol  processing  ocurred  for  the  most  part  as  If  the  CPU  was  always 
available.  The  model  was  designed  to  enable  representing  having  to  wait  to  be 
served  by  the  CPU  but  all  tne  results  obtained  did  not  employ  that  characteristic. 
For  the  cases  where  the  CPU  Speed  Factor  was  changed,  the  processing  times  per 
function  were  reduced  by  a  facto'1  of  2  for  each  change  In  CPU  Speed  Factor  (l.e., 
1.0  was  the  slowest  CPU,  0.5  was  twice  as  fast,  etc). 

The  results  In  the  two  figures  Indicated  a  potential  capability  of 
achieving  throughputs  for  long  sized  TCP  messages  (11,440  bits)  ranging  from 
approximately  650  kb/s  (Speed  Factor  of  1.0)  up  to  5.2  Mb/s  (Speed  Factor  of 
0.125).  These  results  were  obtained  for  the  case  of  a  single  transmitting  node 
with  one  open  TCP  connection  and  no  other  traffic  loadings  on  the  Ethernet  cable 
(no  collisions).  This  represented  the  theoretical  best  obtainable. 

In  each  condition  measured,  the  Input-output  results  remained  linear  up 
to  a  point  and  then  saturation  occurred  where  for  more  Input  the  corresponding 
output  would  not  continue  to  Increase. 
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Figure  5.17.2.5.2-1.  Input  Versus  Throughput  Rate  for  CPU 
Factors  1,  U.5  (Single  TCP  Connection-Single  Node) 
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Figure  5.17.2.5.2-2.  Input  Versus  Throughput  Rate 
for  CPU  Factors  C.25,  U.125  (Single  TCP  Connection-Single  Node) 
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Figure  5.17,2.5.2-3.  Throughput  Rata  Versus  Max  Queue  Length 
(Single  TCP  Connection  -  Single  Mode) 
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Figure  5.17.2.5.2-4.  Throughput  Rate  Versus  One-Way  Delay 
Time  {Single  TCP  Connection  -  Single  Mode 
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Throughput  Rate  Versus  Max  Queue  Length  for  Single  TCP  Connection  - 

Single  Mode  (Figure  5.17. 2. 5. 2-3) 

As  the  model  was  run  In  the  previous  examples  for  TCP.  data  was 
gathered  on  the  TCP  Receive  Module  Queue  Length.  The  results  showed  a  constant 
value  of  aporoximately  1  for  a  range  on  increasing  throughput  up  to  a  point,  where 
thereafter  the  size  of  the  queue  increased  an  order  of  magnitude.  It  was 
concluded  this  condition  is  what  produced  the  throughput  saturation  effects  for 
the  four  cases  previously  shown. 

Throughput  Rate  Versus  One-Way  Delay  Time  for  Single  TCP  Connection  - 

Single  Node  (figure  5.17.2.5,2-4) 

One-way  delay  time  data  was  obtained  while  the  CPU  Speed  Factor  was 
changed  from  1.0  through  0.125.  The  results  showed  that  faster  CPU  speed 
(corresponding  reduced  protoco1  processing  time)  improved  performance  by  reducing 
the  one-way  delay.  For  each  condition,  there  was  a  range  of  operation  where  delay 
was  minimal  and  constant  up  to  a  point  In  throughput  where,  upon  reaching 
saturation,  the  delay  increased  to  very  large  values. 

CPU  Speed  Factor  Versus  Throughput  for  Single  TCP  Connection  -  Single 

Node  (Figure  5.17.2.5.2-5) 

This  figures  show  the  maximum  values  of  TCP  throughput  that  were 
obtained  at  the  saturation  points  for  the  four  values  of  CPU  Speed  Factors. 

Channel  Utilization  Versus  Throughput  for  Multiple  TCP  Connections  - 

Multiple  Nodes  (Figure  5.17,2,5.2-6) 

The  model  was  reconfigured  to  create  the  case  where  three  nodes  were 
simulated,  with  single  and  multiple  TCP  connections  established  among  them.  In 
addition,  loading  nodes  were  added  to  cause  the  total  Ethernet  channel  (medium)  to 
be  varied  from  approximately  5  to  83  percent  loading  (0.5  to  8.3  Mb/s). 

Three  different  TCP  message  sizes  (11,440  bits,  512  bits  and  8  bits) 
were  employed  on  different  connections  and  operated  on  the  Ethernet  channel 
concurrently.  Measurement  results  we  obtained  which  Indicated  that  over  a  large 
range  of  loading,  throughput  was  not  affected.  Around  the  65  percent  loading 
region  total  system  throughput  began  to  decrease.  The  results  for  throughput  were 
not  set  to  indicate  maximum  attainable  but  representative  of  typical  system 
operation  under  the  condition  of  loading  from  other  nodes. 
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Figure  5. 17. 2. C. 2-5.  CPU  Speed  Factor  Versus  Throughput 
(Single  TCP  Connection  -  Single  Node) 
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Figure  5.17.2.5.2-5.  Channel  Utilization  Versus  Throughput 
(Multiple  Connections  -  Multiple  Access) 
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Channel  Utilization  Versus  One-Way  Delay  Time  for  Multiple  Connections 
Multiple  itodes  for  fixed  11,440  bit.  512  bit  and  8  bit  Message  Sizes 
(Figures  5.17. 2.S. 2-7  through  5.17.2.5.2-9) 

These  figures  show  1-way  delay  Measurement  results  obtained  for  the 
previous  three  different  message  sizes  for  TCP  throughput.  The  values  for 
Ethernet  and  IP  are  the  average  delays  whereas  both  the  average  and  maximum  delays 
are  given  for  TCP.  As  Was  shewn  earlier,  Ethernet  average  delay  remained 
essentially  flat  whereas  Ethernet  maximum  delay  Increased  sharply  as  60-65  percent 
and  greater  channel  loadings  were  experienced. 

The  results  indicate  how  this  maximum  Ethernet  delay  characteristic 
affects  the  protocol  layers  above  It  (TCP,  IP).  Up  to  around  50  percent  channel 
utilization,  delay  was  constant  but  as  loading  was  increased,  delays  Increased  to 
large  values,  even  though  throughput  remained  constant  up  until  about  65  percent. 
5.17.2.5.3  Other  Results 

Network  Minimum  Header  Overhead  Pie  Chart  (Figure  5.17.2.5.3) 

This  figure  shows  the  relationship  of  protocol  headers  (In  percentage) 
to  that  of  actual  TCP  Client  or  User  data,  for  the  message  sizes  of  8  bits,  512 
b1:.j  ana  10,240  bits.  For  the  8-blt  case,  data  represents  only  1  percent 
(overhead  of  99  percent)  while  for  512  bits,  data  Is  46  percent  (overhead  54 
percent)  and  for  10,240  bits,  data  Is  94.5  percent  (overhead  of  5.5  percent). 
Protocol  Layered  Data  Rates  (Table  5.17.2.5.3) 

This  table  shows  the  throojhput  data  rates  as  a  function  of  protocol 
layer  when  TCP,  IP,  LLC  and  Ethernet  were  used  together  to  produce  a  TCP  Client 
rate  of  272  kb/s  for  11K  bit  message  size. 

5.18  TCP  Alternatives  for  Intra-LAN  use 

This  reports  on  three  references  works  [49,  50,  51]  which  examined  TCP 
for  use  In  LAN's  where  the  predominate  traffic  would  be  intra-LAN  oriented. 

5. !8.1  The  Local  Network  Transmission  Control  Protocol  (LNTCP)  Alternative 
Reference  [49],  by  a  member  of  the  Naval  Ocean  Systems  Center, 
discussed  possible  approaches  to  applying  TCP  within  a  LAN-based  command  center 
environment.  It  concluded  that  "because  of  their  very  different  topology, 
transmission  media,  and  other  features,  delay,  throughput,  and  cost  considerations 
Indicate  that  long  haul  networks  and  local  area  networks  should  use  very  different 
host-to-host  communication  protocols.  Long  haul  networks  require  complex 
protocols  which  efficiently  utilize  communication  channel  bandwidth  at  tfu  expense 
of  processing  time.  Local  area  networks  require  simple  protocols  which  expend 
communication  channel  bandwidth  In  order  to  reduce  processing  time."  The 
reference  goes  on  further  In  considering  Its  conclusions,  as  follows: 
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Table  5.17.2.5.3.  Protocol  Layered  Data  Rates 


Channel  Rate 

10.0000000  Hb/s 

10000.0000  kb/s 

Ethernet  All  Oata  Rate 

0.3000896  Mb/s 

300.0896  kb/s 

Ethernet  Client  Oata  Rate 

0.2901819  Mb/s 

290.1819  kb/s 

LLC  Client  Oata  Rate 

0.2886575  Mb/s 

288.6576  kb/s 

IP  Client  Data  Rate 

0.2810363  Mb/s 

281 .0363  kb/s 

TCP  Input  Data  Rate 

0.2722720  Mb/s 

272.2720  kb/s 

TCP  Client  Data  Race 

0,2718907  Mb/s 

271.8907  kb/s 

UDP  Client  Data  Rate 

0.0000000  Mb/s 

0.0000  kb/s 

Average  Interxml t  Time 

0.0203467  sec 

20.3467  msec 

Conditions:  2  nodes  and  1  TCP  Connection 

11k  bits  message  size  (fixed  size) 
Interarrival  time  of  41  ms  (averaged) 
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"TCP  Is  a  complex  protocol  with  features  designed  to  efficiently 
utilize  the  communication  facilities  In  a  long  haul  network  such  as  the  ARPANET. 
Any  local  network  Interconnected  with  the  ARPANET  which  uses  TCP  as  Its  only 
host-to-host  protocol  will  achieve  relatively  simple  Internetwork  communications 
at  the  expense  of  definitely  suboptlmal  Intra-network  communication  performance." 

It  goes  further: 

"An  alternate  approach  would  be  to  Implement  a  Local  Network 
Transmission  Control  Protocol  {LNTCP )  which  retains  many  of  the  features  of  TCP, 
but  substitutes  for  the  TCP  flow  control,  resequencing,  and  duplicate  detection 
features,  and  which  uses  a  much  larger  packet  size  than  the  ARPANET.  Such  a 
protocol  should  provide  for  efficient  local  Intra-network  communication 
performance  while  allowing  for  good  Internetwork  communication  performance  as 
well." 

Lastly  it  states: 

"Each  Command  Control  NetwoHc  node  should  be  able  to  Implement  both  the 
LNTCP  and  TCP  with  a  limited  amount  of  effort  and  cost.  3e1ng  Identical  In  many 
respects,  the  two  protocols  could  share  substantial  portions  of  software.  Those 
sections  of  software  unique  to  either  LNTCP  or  TCP  could  be  either  executed  or 
bypassed,  depending  on  the  situation." 

5.18.2  An  Extended  Backplane  Approach  to  LAN  Interprocess  Communications 

A  paper  by  Cherlton  [50]  at  Stanford  University  recently  described  a 
novel  approach  to  LAN  Interprocess  communications  which  departs  from  the  use  of 
standard  TCP  at  almost  the  extreme.  A  distributed  operating  system,  termed  the 
V-System  (pronounced  "Vee"),  Is  a  system  at  Stanford  which  uses  Ethernet. 

However,  Is  uses  the  Ethernet  LAN  as  an  extended  backplane  to  connect  a  collection 
of  diskless  SUN  workstations  and  server  machines.  A  distributed  kernel  provides 
uniform,  transparent  message-based  Interprocessor  communication  on  a  single 
workstation  and  between  processes  on  different  workstations. 

The  paper  reports  the  following: 

“We  have  a  strong  need  and  desire  to  support  and  use  standard 
internetwork  protocols,  in  particular,  being  part  of  the  ARPA  Internet  community, 
the  IP/TCP  family  of  protocols.  Normally,  use  of  Internetwork  protocols  Is  not  a 
problem.  However,  our  use  of  a  local  network  as  an  extended  backplane  means  that 
local  network  performance  must  be  compared  to  Intra-machine  communication 
performance,  not  long-haul  network  performance.  Using  this  comparison,  we  argue 
that  using  internetwork  protocols  on  a  local  network  for  interprocessor 
communications  leads  to  minimal  benefits  and  significant  costs." 
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The  paper  further  discusses  the  characteristics  of  distributed 
processing  and  Internetwork  protocols  as  follows: 

"Internetwork  protocols  do  not  provide  a  communication  model 
well-suited  to  distributed  systems.  A  distributed  system  requires  a 
transport-level  facility  for  Interprogram  and  possibly  Intraprogram  communication 
that  works  transparently  within  a  single  machine  as  well  as  across  the  network 
between  machines.  Because  of  the  predominant  use  of  procedure  cal  1-1  Ike 
communication  within  systems  (even  message-based  systems)  the  appropriate  model  is 
some  form  of  request-response  transaction  style  communication,  where  a  transaction 
typically  consists  of  requesting  a  service  and  getting  a  response  back." 

In  the  concluding  remarks,  the  following  was  given: 

"The  distributed  V-Systera  achieves  high  performance  on  the  local 
network  with  a  transparent  network  Interprocessor  communication  facility  based  on 
a  simple  request-response  Interkemel  protocol.  Measurements  Indicate  that  this 
facility  gives  performance  superior  to  Internetwork  protocols  and  the  performance 
Is  sensitive  to  additional  protocol  overhead.  In  particular,  processor  time  Is 
the  critical  factor.  The  Interprocessor  communication  facility  suffices  as  the 
single  transport-level  communication  mechanism  on  the  local  network  as  well  as  for 
all  Interprogram  communication,  whether  local  or  distributed.  It  Is  as  efficient 
to  use  for  local  network  file  access,  file  transfer  and  terminal  access  as  more 
specialized  protocols." 

5.18.2  Protocol  Functional  Approach  to  IAN 

A  paper  by  Schnel dewind  [51],  with  the  Naval  Post  Graduate  School, 
discusses  three  approaches  for  solving  the  interconnection  problem:  network 
access,  network  service,  and  protocol  functions.  Of  the  three,  the  protocol 
method  provides  one  set  of  protocol  functions  for  the  local  network  and  another 
set  for  the  long-distance  network,  where  some  functions,  or  corresponding  network 
layers,  are  common  to  both  networks. 

When  trying  to  optimize  local  network  conmunlcatlons,  as  the  primary 
user  objective,  the  paper  advocates  "using  only  those  layers  and  protocols 
necessary  for  local  network  operation,  -  ‘  lie  also  providing  communication  between 
local  network  via  the  long-distance  network." 

The  paper  states  further: 

"It  Is  not  necessary  to  implement  all  ISO  layers  in  the  local  network 
to  achieve  effective  intra-local  network  communication,  nor  Is  Implementation 
necessary  to  connect  to  a  long-distance  network.  However,  the  number,  types,  and 
characteristics  of  the  layers  utilized  determine  the  efficiency  of  Interlocal 
network  communication  (l.e.,  communication  over  the  long-distance  network)." 
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"The  protocol  functions  approach  solves  the  problem  of  local  network 
communications  efficiently,  but  at  hi gh  hardware  and  software  costs.  Its  use  of 
the  protocol  translation  In  the  gateway  necessitates  a  complex  network  Interface.* 

In  an  example  approach  cited,  the  following  was  given: 

“The  protocol  functions  approach  provides  only  those  protocols  In  the 
local  area  network  that  are  needed  to  support  this  type  of  communications 
environment.  The  LAN  has  no  need  for  the  services  provided  by  the  transport  and 
network  layers,  because  routing,  switching,  and  traditional  flow  control  and 
congestion  control  services  are  unnecessary.  The  presentation  layer.  Implemented 
In  the  terminal  management  module,  will  accept  data  from  the  application  process 
and  convert  It  to  LAN  format.  Conversely,  It  will  accept  messages  In  the  LAN 
format  and  convert  them  to  the  appropriate  application  process  format."  This  Is 
Illustrated  by  Table  5.18.3  and  Figure  5.18.3. 

"To  simplify  the  LAN  design,  the  following  message  formats  are  used: 

1.  TCP  format  will  be  provided  to  the  DDN  by  the  NC  module  whenever 
communication  on  the  DON  Is  necessary.  A  much  simpler  format  will 
be  used  for  the  Intra-LAN  communication. 

2.  End-to-end  virtual  circuit  connections  and  breaking  of  a  complete 
message  Into  fragments,  services  normally  provided  by  the  transport 
layer,  will  be  Implemented  In  each  of  the  LAN  modules.  End-to-end 
in  this  context  refers  to  the  logical  communication  linkage  between 
two  modules  separated  by  <*  relatively  short  distance;  In  some  cases 
the  two  modules  could  be  In  the  same  hardware  unit." 

In  closing,  the  paper  stated:  "Where  optimization  of  intra-local 
network  performance  Is  desired,  this  Is  accomplished  by  using  only  those  layers 
and  protocols  that  are  compatible  with  and  can  take  advantage  of  the 
characteristics  of  local  networks." 

5,19  Generic  Gateways  for  LAN  Interoperability 
5.19.1  Introduction 

Local  area  networks  (called  LAN's)  are  the  latest  technology  to  offer  a 
major  breakthrough  for  building  distributed  Information  systems.  LAN's  provide 
high  data  rate  (1-200  Mb/s)  peer-to-peer  digital  conmunlcatlons,  at  low  cost,  for 
Interconnecting  system  elements  In  a  localized  area  (l.e.,  a  room,  building  or  a 
campus).  Tradeoffs  In  throughput- del  ay  performance,  media  and  media  access 
method,  topology,  connection-connectionless  transfer  service  and  methods  for 
Interconnecting  LAN's,  are  possible  when  choosing  a  solution  to  a  system's  problem. 
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Table  5.18,3.  Use  of  ISO  Layers  lit  LAM  Design 


Layer 

Application 

Presentation 

Session 

Transport 

Network 

Data  Link 

Physical 


LAN  Coraraunl cation 
Protocol /Module _ 

Application  Process  Modules 

Terrain* '  Management 

Session  Services 


Local  Communications 


DON  CogMunl cation 
Same  as  for  LAN 
Terminal  Management 
Session  Services 
TCP 
IP 

Specified  by  the  DuN 
(Various  Protocols) 


Local  Communications 


This  discusses  Issues  associated  with  interconnecting  LAN's  to  other 
LAN's  and  to  non-LAN's.  This  Is  dtscussed  in  the  context  of  the  emerging 
International  consensus  for  now  to  Interconnect  open  systems,  the  need  to 
understand  the  IEEE  802  family  of  LAN  protocols,  the  principles  which 
Interconnection  is  based  upon,  a  generic  family  of  gateway  interconnection 
elements  and  example  Interconnection  situations.  The  beneficial  Impact  of 
understanding  the  Issues  presented  herein  can  be  realized  In  the  economic  savings 
and  performance  gain  achieved  through  the  application  of  these  principles  to  real 
systems  problems. 

This  material  Is  based  upon  reference  [60j  which  deals  with  generic 
gateways  usable  to  Interconnect  LAN-based  heterogeneous  end  system  or  system 
elements. 

5, la. 2  Objectives 

This  provides  insight  to  the  designers,  developers  and  users  of  mixed 
media-based  LAN's,  Into  the  bigger  systems  picture  of  which  LAN's  are  a  small  but 
very  important  part.  Sometimes  In  the  quest  to  apply  better  performing  LAN 
technology  for  achieving  higher  and  higher  data  rates,  it  Is  easy  to  not  see  how 
this  capability  Is  to  fit  Into  the  overall  system.  In  the  context  of  this 
discussion,  the  bigger  picture  Is  one  where  systems  elements  (computers,  storage, 
processing,  users,  resources)  will  oe  physlcally/loglcally  distributed. 
Interconnected  together  by  an  Interprocess  communications  subsystem  employing  LAN 
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technology,  and  then  functionally  Integrated  to  Interoperate  as  a  virtual  global 
system  to  the  users.  A  global  network  operating  system  will  manage  the  allocation 
and  use  of  system  resources. 

5.19.3  Open  Systems  Interconnection 

International  consensus  has  now  been  uchleved  on  the  way  to 
Interconnect  systems  In  an  open  (nonproprietary )  way  [5],  This  agreement,  reached 
In  1984  by  both  the  ISO  (International  Standards  Organization)  and  the  CC1TT 
(International  Consultative  Committee  of  Telegraphy  and  Telephony)  are  docuoented 
In  ISO  7498  and  CCITT  X.200  documents  for  Open  Systems  Interconnection  (OSI). 

The  services  provided  by  the  seven  layers  of  the  OSI/RM  can  ba  divided 
Into  three  main  regions,  as  follows: 

Networking  Utilities  -  Layers  7,  6,  5 

Host-to-Host  Transport  and  Internetworking  -  Layers  4,  3 

Subnetwork  Transmission  (Local  and  Wide  Area  Networks)  -  Layers  3,  2,  1 

and  Media  0 

The  technologies  associated  with  LAN's  fall  within  the  subnetwork 
transmission  region  to  form  one  of  the  major  emerging  technology  foundations  for 
supporting  the  ability  to  build  truly  distributed  processing  systems.  Public  and 
private  wide  area  networks  (WAN's)  provide  a  range  of  alternatives  In  selection  of 
design  solutions  for  layers  3-0  of  the  OSI/RM.  Overall  responsibility  for 
end-to-end  data  transport  reliability  of  packets  fall  to  the  protocols  which 
implement  layers  4  and  3.  Finally,  protocols  of  layers  7,  5,  and  5  respectively 
deal  with  the  semantics,  syntax  and  organization  of  Information  exchanges.  In  the 
highest  region  of  the  OSI/RM,  a  set  of  generic  (canonical)  virtual  protocols 
provide  a  set  of  comnonly  used  networking  utilities  to  the  ultimate  end  system 
user.  Examples  of  networking  utilities  are  virtual  file,  terminal,  job,  message, 
document  and  resource  management  [17], 

5.19.4  LAN  Architecture  and  Protocols 

To  date,  the  most  widely  documented  and  supported  consensus  for  the 
architecture  and  protocols  for  LAN's  Is  represented  by  the  family  of  standards 
developed  by  the  IEEE  Computer  Society's  Project  802  [41],  There,  three  methods 
for  accessing  media  were  developed  based  upon  CSMA/CD,  Token  Bus  and  Token  Ring 
operations.  A  common  agreement  was  reached  for  the  next  level  of  protocol  called 
Logical  Link  Control  (LLC).  Together,  these  span  the  lowest  region  of  the  OSI/RM. 
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The  CSMA/CD  and  Token  Bus  protocols  were  developed  to  operate  with  • 
broadcast  bus  topology  while  the  Token  Ring  was  for  point-to-point  topology.  Coax 
cable  was  the  medium  specified  for  the  bus  while  twisted  pair  and  fiber-optic 
cable  were  Intended  for  the  point-to-point  cases.  Nevertheless,  fiber-optic  cable 
technology  employing  a  star  arranged  topology  Is  capable  of  supporting  the  Token 
Bus  medium  access  control  protocol. 

5.19.5  Connectionless  and  Connection-Oriented  Services  [61] 

In  order  to  interconnect  elements  of  the  802  architecture,  a  closer 
understanding  of  the  services  provided  by  the  LLC  and  MAC  entitles  Is  necessary. 
First,  both  the  MAC  and  LLC  provide  a  connectionless  service,  sometimes  called 
datagram.  However,  an  optional  connection-oriented  service  may  be  provided  by  LLC 
In  addition  to  connectionless.  With  the  connectionless  service,  a  single  data 
frame  at  a  time  comprises  the  span  of  communications  control.  That  Is,  one  MAC 
entity  In  a  station  transmits  a  single  MAC  frame  to  one  or  more  other  stations  by 
way  of  tr.e  Interconnected  media.  The  receiving  statlgn(s)  process  that  entity  as 
a  stand-alone  message.  If  successful  {having  no  detected  error  and  addressed  to 
that  station),  then  the  single  message  Is  accepted  and  Its  control  fleld(s) 
contents  acted  upon,  else  the  frame  Is  discarded. 

Recovery  from  discarded  frames  may  be  performed  by  the  MAC  sending 
station.  In  the  case  of  Token  Bus  and  Token  "Ring  and/or  a  higher  protocol.  In  the 
CSMA/CD  case,  lost  frames  are  ntft  recovered  by  the  sending  station's  MAC  entity. 

A  higher  layer  protocol  entity  would,  upon  timing  out,  attempt  a  retransmission. 
When  LLC  employs  the  connection-oriented  service,  the  sending  LLC  entity  Initiates 
recovery  for  CSMA/CD,  Token  Bus  and  Token  Ring  for  non-MAC  frames  either  triggered 
by  a  time-out  event  or  based  upon  Information  sent  to  It  from  a  destination 
station  Indicating  the  loss  of  a  sequenced  Identified  LLC  message  frame  (MAC 
information  field).  When  LLC  employs  the  connectionless  service.  It  does  not 
perform  any  recovery  operation  In  the  event  cf  a  lost  frame.  A  higher  layer 
(transport)  may  perform  this  recovery. 

A  significant  distinction  can  be  made  between  these  two  types  of 
service.  When  connectionless  service  Is  employed,  each  message  frame  Is  the 
entire  entity  In  space  over  which  control  spans,  whereas  with  connection-oriented 
service  there  Is  a  time  orientation  during  which  control  is  spanned.  With 
connectionless  service,  sending  and  receiving  stations  maintain  minimum  (or  no) 
state  Information,  but  with  connection-oriented  there  Is  both  state  and  control 
block  descriptive  data  iranaged  at  both  ends  of  the  established  connection. 
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Connection-oriented  service  employs  connection  open,  data  transfer  and 
connection  close  phases,  while  connectionless  Is  always  In  the  data  transfer 
phase.  These  differences  In  operational  characteristics  hold  at  any  layer  In  the 
OSI/RM  where  either  or  both  forms  of  service  are  performed.  Connection-oriented 
service  In  addition  performs  sequencing,  flow  control  and  error  recovery 
operations  which  connectionless  does  not  perform. 

5.19.6  Principle  of  Interconnection 

LAN  and  WAN  networks,  being  offered  by  vendors  and  public  carriers.  In 
spite  of  the  evolving  standards  work,  are  heterogeneous  In  many  Instances. 

Systems  designers  will  be  faced  with  having  to  Interconnect  them  together  In  order 
to  build  an  Integrated  global  system.  The  main  objective  or  Interconnecting 
networks  Is  the  extension  of  communications  facilities  to  a  larger  population  of 
users. 

This  problem  of  network  Interconnecting  was  examined  and  reported  on  by 
Glen  and  Zimmermann  [62].  In  that  paper,  a  set  of  principles  is  laid  out  for 
network  Interconnections  based  upon  several  simple  but  powerful  structuring 
techniques.  These  techniques  stress  multiplexing,  switching,  cascading,  wrapping, 
layering  and  the  equivalence  of  services. 

In  order  to  Interconnect  networks,  they  must  exhibit  the  following: 

1.  Levels  of  equivalent  services,  to  be  possibly  merged  Into  a  global 
network  offering  these  services 

2.  A  set  of  properties  which  make  Interconnection  viable,  such  as 
cascadablllty  of  services,  multiplexed  Interfaces  and 
Interpretation  of  a  global  address  space 

If  these  constraints  are  not  satisfied,  the  network(s)  must  bo 
modified,  usually  by  wrapping  It  (end-to-end)  In  an  additional  layer  which 
externally  exhibits  the  required  Interconnection  capability. 

Multiplexing 

A  mechanism  Is  employed  by  multiplexing  In  either  space  or  time  to 
share  a  resource  among  several  using  entitles. 

Switching 

Switching  Involves  the  Interpretation  of  addresses  and  routing  of 
requests  when  resources  are  shared. 
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Cascading 

This  consists  of  joining  a  series  of  entitles  In  a  linear  string  which 
forwards  messages  or  propagates  activities  along  the  cascade.  Cascading  Is  ttr 
only  way  for  communl cation  between  entitles  which  are  not  directly  connected  to 
each  other.  This  Is  like  joining  two  similar  service  networks  by  plugging  them 
together. 

Equivalence  of  Services 

Interconnection  of  networks  can  only  be  performed  at  a  level  providing 
equivalent  services  on  either  side  [62,  63,  64].  In  addition,  these  services  must 
be  cascadable.  Networks  offering  Identical  services,  such  as  connectionless  or 
connection-oriented,  can  be  Interconnected  without  great  difficulty. 

If  this  Is  not  the  case  (equivalence  of  service),  either  a  common 
subset  of  the  service  has  to  be  chosen  {subnetwork  de-enhancement)  or  a  new 
(subnet  enhancement)  sublayer  has  to  be  added  on  top  of  a  "poor"  subnetwork  to 
achieve  equivalent  services  [62]. 

Protocol  Conversion 

When  two  subnetworks  are  being  Interconnected  which  possess  equivalent 
services  (semantics)  but  have  different  formats,  then  protocol  conversion  must  be 
performed  [62].  Protocol  conversion  consists  of  expressing  the  semantics  carried 
by  one  protocol  In  the  message  formats  and  protocol  syntax  of  the  other.  In  other 
words.  It  consists  of  converting  the  necessary  message  formats  and  protocol  syntax 
to  preserve  the  protocol  semantics. 

When  the  two  architectures  being  Interconnected  carry  protocol 
functions  which  differ  In  their  distribution,  then  composite  functions  in  two  or 
more  layers  must  be  considered  in  order  to  find  a  point  where  the  two  services  are 
equivalent.  In  this  approach,  protocol  conversion  can  be  extended  to  protocols 
pertaining  to  two  (or  more)  layers,  with  the  possibility  of  converting  the 
protocol  of  level  N  of  one  architecture  Into  the  protocol  of  level  M+1  of  the 
other  architecture.  On  the  other  hand,  when  two  protocols  belonging  to  different 
architectures  support  different  sets  of  functions,  protocol  conversion  can  be 
applied  effectively  only  to  the  functional  subset  common  to  both  protocols. 

Lastly,  when  two  protocols  are  not  "convertible,"  the  only  possible  solution  for 
communicating  with  the  other  entity  Is  actually  to  Implement  the  other  entity's 
protocol  [67]. 
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5.19.7  Gateways  for  Interoperability 

A  set  of  gateway  elements,  or  building  blocks,  are  needed  In  order  to 
support  full  LAN  Interoperability  In  a  heterogeneous  world.  This  paragraph 
provides  a  summary  of  four  generic  types  of  gateways,  spanning  the  full  range  of 
the  OSI/RM.  Appendix  G  presents  a  design  approach  discussion  where  each  of  these 
four  Is  discussed  In  greater  depth  and  an  application  approach  presented. 

Gateways  are  communications  processing  nodes  used  to  Interconnect 
networks  employing  heterogeneous  protocols.  Four  types  span  the  „even  protocol 
layers; 

•  Bridge  Gateway  (thrvjgh  layer  ?) 

«  Packet  Switching  Gateway  (through  layer  3) 

t  Protocol  Conversion  Gateway  (layers  4-7) 

•  Open  End  Systems  Interconnection  Gateway  (layers  1-7  between 
heterogeneous  end  systems) 

Bridge  Gateway  (through  layer  2) 

This  Is  employed  to  join  two  media  access  control  LAN  segments 
together;  these  may  be  homogeneous  or  heterogeneous.  Logical  Link  Control  using 
protocols  is  extended  across  joined  physical  LAN  segments.  When  just  two  like 
media  are  joined  this  Is  called  a  repeater  (baseband)  or  frequency  translator  (In 
the  case  of  broadband).  These  can  perform  some  of  the  address  filtering/blocking 
in  support  of  multilevel  security  for  joined  LAN's. 

Packet  Switching  Gateway  (through  layer  3) 

This  Is  employed  to  interconnect  LAN  to  LAN  or  LAN  to  WAN  to  LAN 
subnets  to  form  an  Internet.  Underlying  layers  of  protocols  may  be  homogeneous  or 
heterogeneous.  However,  LAN  logical  links  or  WAN  network  virtual  circuits  are 
terminated  at  gateway.  An  end-to-end  Internet  protocol,  employed  on  top  of  joined 
LAN-WAN  protocols,  performs  host-to-host  packet  switching,  routing,  fragmentation, 
reassembly. 

Protocol  Conversion  Gateway  (layers  4-7) 

This  Is  employed  to  Interface  two  heterogeneous  network  system's  upper 
layer  protocols.  This  type  converts  from  vendor  A  to  vendor-  B  specific  protocol. 
Gateway  functions  are  very  vendor  protocol  ana  application  specific  and  difficult 
to  standardize. 
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Open  End  Systems  Interconnection  Gateway  (layers  1-7  Join  heterogeneous 
end  systems) 

This  type  Is  employed  to  Interconnect  In  an  open  manner  (nonproprietary 
way)  multiple  vendor  end  systems,  each  employing  their  own  Internal  heterogeneous 
protocol  suites,  to  create  a  cooperative  Global  Network  Operating  System  set  of 
networking  utility  services. 

This  type  spans  layers  1-7  and  provides  a  set  of  generic  networking 
utility  services,  host-to-host  transport.  Internetworking  and  LAN/WAN  subnet 
services.  This  type  provides  services,  functions  and  protocols  necessary  to 
support  fully  distributed  data  processing.  It  performs  networking  utility 
functions  employed  In  bul'lding  a  distributed  network  operating  system.  The 
Internal  archl tectures  of  these  end  systems  are  not  addressed  by  the  Open  System 
Interconnection  Network  Utility  protocols.  Two  ir^jor  architectures/protocol 
suites  exist:  DOD's  and  ISO's.  The  DOD/ISO  proposal  suites  provide  similar 
functionality  for  Interprocess  communication  between  application  processes 
residing  in  heterogeneous  or  homogeneous  end  systems. 
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6.0 

6.1 


CONCLUSIONS 

General 


This  section  presents  a  set  of  concise  statements  of  the  conclusirns 
reached  from  the  studies'  and  investigations'  results  given  In  Section  5.0.  This 
Is  arranged  in  the  same  order  of  presentation  as  that  g1*»en  In  Section  5.0. 

6.2  Strategic  Command,  Control  and  Communications 

1.  C^  must  survive  and  offer  sufficient  flexibility  to  identify, 
reconstitute,  and  employ  surviving  assets  for  trans-  and 
post-attack  command  and  control. 

2.  Packet-switching,  end-to-end  network  security,  and  distributed 
knowledge  and  data  bases  are  key  technologies  needed. 

3.  A  capability  is  needed  for  reconstituting  remaining  partitioned 
assets,  resources  and  data  bases.  An  automated,  possibly 
knowledge-based,  network  management  capability  Is  needed.  Unified 
Internet  working  protocols  and  gateways  will  be  required. 

4.  A  layered  architecture  for  organizing  the  command  and  control 
systems  applications  functions  Is  possible  and  could  aid  In 
developing  needed  applications  and  systems  software.  An  extension 
of  an  OS I  approach  to  layering  appears  useful. 

6.3  Tactical  Command  and  Control-Interoperability  and  Survivability 

1.  For  the  1990's,  tactical  C2  systems  will  need  to  be  Interoperable 
across  the  military  services  and  their  many  operational  and  support 
systems. 

2.  Principal  requirements  are  robustness,  survivability,  high  degree 
of  Interconnectabillty,  high  data  transmission  rates  and 
Interoperability. 

3.  A  common-user,  tactical  Information  exchange  structure  Is  needed. 

4.  A  tactical  system  connunlcatlor.s  protocol  reference  model  and 
sulte(s)  of  protocols  are  needed.  This  should  be  a  joint  services 
effort. 

5.  A  need  exists  for  development  of  network  management  and  control 
concepts  and  protocols,  especially  with  respect  to  precedence, 
security  and  auditing  features. 

6.  New  concepts  are  needed,  like  the  mobile  Cellular  Command  Post,  to 
ensure  the  survivability  of  a  conwand  center  In  a  tactical  nuclear 
environment. 
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7.  Issues  are  raised  as  to  row  to  distribute  and  manage  information 
data  bases  and  processing  resources  In  a  real-time  environment. 

8.  A  reconstitution  problem  exists,  similar  to  that  Identified  for 
strategic  C3.  Automatic  reconstitution  capability  Is  a  need  to 
support  this. 

9.  Computer  processing  machine  resources  will  exhibit  a  high  degree  of 
heterogeneity.  A  need  exists  to  solve  this  Interoperability 
problem. 

Protocol  Standards  for  Military  Use 

1.  Mo  single  technology  Is  Ideal  for  all  applications,  yet  the  full 
collection  of  systems  must  Interoperate. 

2.  D00I  4120.20  requires  the  adoption  of  Industry  standards  as  DOD 
standards,  in  lieu  of  development  ana  promulgation  of  new 
documents.  Special  exceptions  can  be  made. 

3.  Currently,  use  of  DOD's  TCP  and  IP  protocols  appears  justified  to 
ensure  Interoperability  *hen  Interworking  through  wide  area 
networks.  Intra-LAN  use  needs  further  cons1de»«;t1on. 

4.  A  new  Kultlnet  Gateway  approach  Is  Intended  to  normalize  the  use  of 
diverse  wide  area  networks  with  the  TCP/IP  Internet  protocols. 

5.  For  the  longer  term,  000  should  carefully  consider  migration  to 
Interoperate  with  OSI-based  systems,  as  these  new  protocol -based 
machines  beqin  to  predominate  worldwide.  This  Is  particularly 
Important  for  the  higher  layer  distributed  processing  protocols. 

6.  The  Air  Force,  In  1983,  formulated  a  policy  stating  the  TCP  and  IP 
protocols  as  being  Its  standards  for  conncctl on-based  transport  and 
Internet  services  within  packet-oriented  LAN's.  In  furtherance  of 
this,  the  Air  Force  was  developing  a  LAM  architecture  and 
established  the  AFLANSPO  Joint  LAN  Program  Office  to  lead  this 
activity. 

7.  Air  Force  priority  for  use  of  TCP/IP  appears  to  be  attainment  of 
interoperability  at  some  cost  In  performance.  Intra-LAN  use  of 
TCP/IP  needs  further  consideration. 

Protocol  Standards  for  Industry  Use 

1.  The  International  Standards  Organization  work.  In  developing  the 
OSI/RM  and  Its  suite  of  protocols,  was  seen  as  the  key  Indicator  of 


where  Industry  was  going  with  protocols. 


2.  Secondly,  the  direction  IBM  Is  taking  In  extensions  to  Its  SNA  and 
use  of  new  LAN  technology  was  seen  as  another  Important  Indicator. 

3.  The  OSI/RM  Is  Intended  for  Interoperability  among  heterogeneous  end 
systems  or  machines,  whereas  the  IBM/SNA  Is  Intended  for 
homogeneous  systems  and  products. 

4.  Since  the  DOD  environment  was  shown  to  be  highly 
heterogeneous,  the  OSI/PM  work  and  Its  International  scope  seem 
highly  relevant  to  DOD  C3  considerations. 

5.  In  spite  of  OSI,  It  Is  expected  that  In  response  to  users' 

requl rements ,  the  systems  built  on  heterogeneous  architecture  will 
grow  In  number  and  size.  These  systems,  however,  will  be  open.  In 
that  by  use  of  OSI  protocols  they  will  be  capable  of  cooperating 
with  other  systems.  OSI  will  become  the  Interoperability  systems 
gateway  between  heterogeneous  systems. 

6.  IBM's  SNA,  by  way  of  Its  new  Logical  Unit  6.2,  Is  now  taking  on  the 
structure  of  a  truly  distributed  operating  system  (DOS).  This  will 
influence  the  architectures  of  other  DOS  systems  to  be  developed 
and  Is  worth  tracking.  SNA's  packaging  of  protocol  layers  with  a 
Logical  Unit  subsystem  has  merit. 

6.6  Tactical  Air  Control  Command,  Control  and  Communications 

1.  Emphasis  on  concepts  such  as  behlnd-line-of-slght  target 
acquisition  and  weapon  delivery  techniques  Is  generating  an 
Increasing  requirement  for  fast,  accurate  exchange  of  Information 
across  both  functional  and  service  boundaries. 

2.  A  shared  use.  Interconnected,  multiple  link  capability  Is  needed  to 
provide  efficient,  survivafcle  Information  transfer  services  for 
future  C^I  users. 

3.  In  TACS,  the  overall  operational  management  Is  centralized,  but 
control  of  the  execution  Is  decentralized.  A  robust/survlvable  and 
secure  Information  exchange  capability  Is  required. 

4.  The  A  1r  Force's  Master  Plan  for  the  1 990 ' s  (TAFIIS)  calls  for  a 
dispersed,  distributed,  survivable  C3  system.  The  plan's  concept 
calls  for  configuration  In  a  distributed,  modular  architecture  with 
sharing  of  Information  seen  as  the  key  to  surveillance  and 
Intelligence  effectiveness. 
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5.  Lightweight,  flexible,  distributed  Modular  Operation  Centers  have 
been  reconmended  to  use  LAN's  for  Interconnection  to  achieve 
survivability.  The  use  of  Multimedia  to  Interconnect  these  LAN's 
will  Increase  survivability  and  Interoperability. 

6.7  for  the  Tactical  Army  System 

1.  A  need  exists  to  provide  a  high  degree  of  survivability  and 
continuity  of  operations  for  execution  of  the  air/1 and  battle 
through  use  of  a  distributed  tactical  C3  system. 

2.  Distribution  and  dispersal  of  command  posts  are  required  along  with 
their  data  bases. 

3.  The  Command  Post  Network  would  be  a  LAN-based  system  and  exhibits 
characteristics  like  that  discussed  for  the  TACS  C3.  Common 
technologies  are  needed  for  both  missions'  systems. 

6.8  Distributed  Information  Processing  for  C3 

1.  Command  and  control  applications  and  systems  functionality  should 
be  structured  with  a  layered  arcnltecture. 

2.  Heterogeneous  processors  need  to  be  Interoperable  over  networks, 
employing  high  level  protocols  and  packet-switching. 

3.  A  distributed  Internetwork  operating  system  Is  required,  along  with 
a  set  of  generic  C2  software. 

4.  Automated  systems  resource  and  network  management  Is  needed. 

5.  C2  applications  will  Include  real-time,  del  ay- tolerable, 
delay-insensitive,  and  del ay-varl able  sensitive  types. 

6.  Digital  data,  voice,  video.  Imagery,  and  nondigital  forms  of 
Informatlon/data  must  be  handled. 

7.  The  architecture  must  support  the  Interconnection  of  dispersed 
clusters  or  cells  of  LAN-based  processors  into  a  global  system. 

8.  Three  levels  of  operating  systems  are  required:  constituent, 
cluster  and  Intercluster  (global). 

9.  Management  of  the  distributed  processes  and  resources  Is  seen  as  a 
major  need. 

10.  Protocols  are  needed  to  create  a  virtual  network  on  top  of  the 
distributed,  basic  physical  network,  for  file  access  and  transfer, 
data  base  access  and  management,  resource  management,  system 
resource  monitoring,  system  f aul t-tol erance  and  survivability. 
Interactive  user  access  and  others. 
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11.  Enslow's  criteria  for  a  Fully  Distributed  Processing  System  (FOPS) 
should  be  the  basis  for  the  systems  architecture: 

a.  Multiplicity  of  general  purpose  resource  components 

b.  Physical  resource  distribution  through  Interconnecting 
networking 

c.  High  level  operating  system 

d.  System  transparency 

e.  Cooperative  autonomy 

6.9  Operating  Systems  for  Distributed  Information  Processing 

1.  A  global  NOS  or  DOS  form  of  high  level  operating  system  Is 
required  to  manage  the  distributed  system  resources.  The  NOS  form 
builds  on  top  of  the  original  heterogeneous  constituent  or  Local 
Operating  System  while  the  DOS  replaces  It  with  a  uniform 
homogeneous  global  one. 

2.  The  National  Software  Wo'-ks  and  the  Cronus  are  examples  of  the  NOS 
form.  IBM's  SNA,  with  UJ  6.2  services,  appears  to  be  evolving  to 
the  DOS  form. 

3.  Object-based  system  architecture  Is  a  new  concept  In  structuring 
of  operating  systems. 

6.10  National  Software  Works  Network  Operating  Systems 

1.  The  NSW  Is  one  example  of  the  NOS  .'orra  of  global,  or  high  level, 
operating  system.  Implemented  on  a  WAN  (ARPANET). 

2.  It  provided  users  a  uniform  access  to  network-provided  utility 
services  for  accessing  objects  such  as  data,  files,  pi-ograms  and 
computing  services  distributed  around  the  network  on  heterogeneous 
machines. 

3.  The  NSW  Interprocess  communications  exhibited  the  following 
characteristics: 

a.  Front-end  to/from  Work  Manager 

short.  Infrequent,  among  unrelated  processes 

b.  Tool /Foreman  to/from  Work  Manager 

-  short.  Infrequent,  amo.ig  unrelated  processes 

c.  Front  End  to/from  Tool /Foreman 

more  frequent,  short,  continuing,  among  related  processes 

d.  File  Package  to/from  File  Package 

Infrequent,  very  long,  among  related  processes 
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Cronus  DOS 
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1.  Cronus  Is  another  NOS  form  of  high  level  operating  system  but  Is 
Implemented  primarily  on  a  LAN  plus  Internet  capability  through  a 
MAN  (ARPANET). 

2.  It  will  provide  services  for  system  access,  object  management, 
process  management,  authentication,  access  control,  security 
(limited),  symbolic  naming,  Interprocess  communications  and  system 
monitoring.  Cronus  Is  an  object-based  architecture. 

3.  Objects  have  capabilities  which  are  defined  In  access  control 
lists  maintained  by  the  object  managers. 

4.  A  suite  of  high  level  protocols  Is  required  to  enable  the 
distributed  resources  and  the  object  managers  to  cooperate  and 
perform  services. 

5.  A  lower  set  of  protocols  supports  the  resources  and  object 
managers  by  performing  Interprocess  communications. 

6.  The  Cronus  DOS  design  employs  several  protocols.  Some,  like  the 
underlying  Ethernet  and  Transmission  Control  and  Internet 
Protocols  (TCP/IP),  are  industry  and  DOD  standard  forms.  These 
provide  the  basic  Interprocess  communications.  Others,  like  the 
MSF,  SER,  MSL,  OS  and  OOP,  are  new  ones  developed  for  Cronus. 

These  perform  higher  layer  type  protocol  functions.  They 
correspond  to  the  0$T/RM  layers  5,  6  and  7  protocols. 

6. 1 2  Generic  Network  Operating  System  (GNOS) 

1.  To  avoid  the  development  of  a  closed  global  operating  system  set 
of  networking  protocols  for  C”*I,  a  general  representation  was 
developed  for  a  Generic  Network  Operating  System,  called  GNOS. 

2.  A  GNOS  architecture  reference  model  should  be  the  basis  for 
guiding  development  of  C*I  protocols  which  are  open  In  their 
Interoperability . 

3.  GNOS  Is  described  In  terms  of  Its  architecture,  services, 
functions,  subsystems  and  protocols  to  form  the  basis  as  a 
reference  model  for  distributed  processing. 
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4.  Protocols  needed  to  support  GNOS  are  Identified.  These  are 
message-based  transaction  and  file  transfer  stream  types.  A 
networking  suite  is  comprised  of  three  service  regions: 

a.  Networking-wide  Utilities 

b.  Host  to  Host/Internetworking 

c.  Local /Wide  Area  Networking 

In  addition,  resource  manager,  process  and  object  protocols  are 
requl red . 

5.  The  combined  resource  manage  and  networking  utility  protocols, 
plus  the  underlying  Interprocess  communications  protocols,  form 
the  GNOS. 

6.13  Comparison  of  POD  and  ISO  Networking  Protocol  Reference  Models 

1.  Networking  reference  models  provide  very  Important  architectural 
definitions  for  the  services,  f motions,  and  protocols  necessary 
to  accomplish  Interoperability. 

2.  The  D00  and  ISO  communities  have  found  it  necessary  to  develop 
their  own  respective  models. 

3.  For  Interoperability,  adherence  to  particular  protocols  Is 
essential,  whereas  adherences  to  the  architecture  of  the  reference 
model  will  not  ensure  Interoperability  by  Itself. 

4.  There  are  advantages  and  disadvantages  to  using  a  layered  approach 
to  defining  a  netv'fking  architecture;  however,  the  advantages  are 
considered  great,  while  the  disadvantages  are  slight. 

5.  DOD  and  ISO  models  are  similar.  The  bottom  most  network/transport 
services  and  protocols  are  quite  close,  but  the  uppermost  virtual 
utility  type  services  and  protocols  have  been  architected 
differently. 

6.  In  DOO's  upper  layers,  the  functions  and  protocols  are  packaged 
more  Into  vertical  subsystems,  whereas  In  ISO's  upper  laytrs,  they 
have  been  more  formally  structured  horizontally  Into  discrete, 
layers.  Elements  of  both  are  desired  though. 

7.  Some  performance  Improvement  can  be  gained  by  a  soft  layering  of 
protocols,  through  the  sharing  of  Information  across  layer 
interfaces.  IBM's  structuring  element  called  the  Logical  Unit  Is 
a  good  example  of  packaging  otherwise  independent  formal  layer 
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protocols  tcgetiier  Into  a  more  tightly  coupled  task-oriented 
subsystem. 

6.  The  00D  model  provides  the  more  basic  networking  utility 

services/protocols,  whereas  the  ISO  set  Is  more  comprehensive  and 
Is  directed  more  formally  to  apply  object-based  design  for  future 
distributed  processing  applications. 

9.  The  DOU  model  does  not  contain  network  or  resource  management 
protocols,  vhereas  the  ISO  model  Is  developing  a  comprehensive  set 
across  the  full  suite  of  protocol  layers. 

10.  The  OSI/RM  has  now  been  approved  by  both  the  ISO  and  CCITT  for 
International  adoption  and  represents  a  far  larger  base  of  users 
than  does  the  OOD/RM.  Longer  term,  this  can  place  Increasing 
pressure  on  tne  DOD  to  support  the  OSI/RM  protocols  ts  a 
cost-effective  means  to  maintain  Interoperability. 

11.  Thtf  IEEE  802  Project  has  developed  the  currently  leading  Industry 
protocols  for  LAN's.  These  are  undergoing  review  by  the  ISO  for 
international  adoption.  These  protocols  are  usable  with  both  tne 
ISO  and  000  models  as  subnets. 

12.  Three  different  methods  for  media  access  to  a  LAN  and  one  common 
link  layer  method  have  been  developed.  Newer  work  Is  adding 
management  and  Internet  working  capabilities. 

13.  Currently,  the  IEEE  802  work  has  focused  on  the  10-Mh/s  operating 
speed  range  for  LAN's. 

14.  Newer  work  In  the  IEEE  802  Is  locking  at  larger  sized  networks 
than  LAN's  called  Metropolitan  Area  Networks,  or  MAN'S. 

ANSI  100-Mb/s  LAN 

1.  In  the  100-Mb/s  speed  range  for  LAN's,  the  ANSi  X3T9.5  Committee 
Is  developing  the  Fiber  Distributed  Data  Interface  (FDDI ) 
standard.  This  is  to  ee  a  Token  Ring  LAN  using  fiber-optic  cable 
and  will  be  based  on  the  IEEE  802  Token  Ring. 

2.  The  FQOI  will  have  application  in  not  only  front-end  LAN's,  but 
back-end  high  Intensity  computer/storage  data  transfers. 

3 

3.  The  FDDI  could  have  application  potential  for  military  C 
functions  as  an  alternative  to  the  FILAN. 

The  FDDI  exhibits  a  set  of  open  protocols. 


4. 


6. 15  Air  Force  Flexible  Intraconnect  LAH  (FILAN) 

1.  rhe  FILAN,  currently  In  an  Advanced  Development  state.  Is  a 
180-Mb/s  bus-oriented  LAN  Intended  for  high  quantity  use  In  C^l 
applications.  It  provides  speed  capability  at  a  range  beyond  the 
IEEE  802  (18  times)  and  ANSI  FOCI  (1.8  times)  LAN's. 

2.  The  FILAN  services  span  the  same  layers  as  the  IEEE  802  and  goes 
beyond  the  FDQI  to  a  degree.  There  Is  extensive  System  Network 
Management  functionality  built  Into  FILAN. 

3.  Extensive  capacity,  modularity,  flexibility  and  deterministic 
control  features  are  built  Into  the  FILAN. 

4.  A  MIL-STD-1779  User  Interface  has  been  established  to  formalize 
the  method  of  ..iterfaclng  to  the  FILAN  Network  Access  Units  to 
gain  service. 

5.  The  FILAN's  developed  protocols  are  considered  to  represent  a 
closed,  rather  than  open,  set.  Gateway  Interface  devices  would  be 
needed  to  Interoperate  with  Industry  standard  LAN's,  such  as  IEEE 
802  and/or  ANSI  FODI. 

6.  Extensions  to  FILAN  are  considering  the  use  of  mixed  media  cable 
and  radio  paths. 

6.16  LAN  Protocol  Characteristics  and  Effects  v 

1.  There  are  three  principal  topologies  employed  to  build  LAN's: 
star,  bus  and  ring.  Each  offers  its  own  set  of  attributes  and 
limitations. 

2.  Of  the  three,  broadband  bes-oriented  LAN's  offer  the  best  overall 
capability  for  handling  a  mixture  of  voice,  data  and  video 
(employing  modulated  carriers  on  broadband  coax  cable)  but  rings 
offer  the  opportunity  to  employ  wide  bandwidth  fiber-optic  point- 
to-point  cable.  Initially,  broadband  coax  bus  LAN's  will 
outnumber  fiber  optic  rings,  but  In  the  longer  term  the  reverse  Is 
expected  to  occur. 

3.  For  tactical  deployments  in  C3  applications,  a  mixture  of  LAN 
media  Is  going  to  be  required,  not  only  to  exploit  the  use  of  coax 
and  fiber  optics,  but  also  radio  paths  as  well.  A  Multimedia  LAN 
study  currently  Is  under  way  for  RADC  by  Harris  Corporation 
looking  Into  these  Issues  for  extending  the  FILAN. 
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4.  Both  connection-oriented  (virtual  circuits)  end  connectionless 
(datagrams)  services  are  required  of  LAN's.  The  IEEri  802  and  ANSI 
FLiOI  protocols  are  being  developed  to  support  both  of  these 
services.  For  distributed  processing,  the  transaction  mode  of 
Inquiry/response  using  oatagrams  %»1 11  be  the  dominant  form  of 
message  exchange. 

5.  Broadcast  and  multicast  delivery  service,  in  addition  to  the  basic 
singlecast  service,  are  readily  supported  by  bus  and  ring  LAN's. 

6.  In  LAN's,  communication  bandwidth  efficiency  is  traded  off  to 
reduce  delay  caused  primarily  from  protocol  processing  functions. 
Tnls  Is  just  the  reverse  from  the  case  of  WAN's.  More  powerful 
protocol  processing  machines  will  be  needed  In  LAN's,  along  with 
the  wider  bandwldths  at  the  mediums,  to  support  C2  application. 

7.  A  systematic  performance  prediction  and  assessment  capability  Is 
needed  to  enable  systems  engineering  of  the  expected  complex 
LAN-based  configurations.  A  simulation/modeling  tool  Is  one  of 
the  methods,  that.  If  employed  In  this  process  would  Increase 
productivity. 

8.  A  variety  of  media  access  methods  that  exist  to  control  how  LAN 
users  share  the  bandwidth  resource  made  available  fall  Into  two 
categories;  contention  and  deterministic.  Both  can  employ 
distributed  control  methods. 

9.  For  light  tc  moderate  traffic  loads,  the  contention  access 
method(s)  provide  a  lower  cost  solution  with  low  delays  achieved, 
such  as  CSMA/CD  (Ethernet  form). 

10.  Where  traffic  loads  are  expected  to  be  moderate  to  high  ana/or 
where  controlled  delay  has  to  be  a  stringent  criteria,  some  form 
of  deterministic  access  method  has  to  be-  employed,  such  as  Token 
Bus  or  Token  Ring. 

11.  Based  on  analysis,  the  CSMA/CD  offers  an  acceptable  contention 
scheme  for  light  to  moderate  loads  while  the  Token  Access  Methods 
do  for  the  deterministic  approach  when  moderate  to  heavy  loads  and 
controlled  delay  are  criteria.  The  Token  Ring  Is  superior  to  the 
Token  Bus  by  a  small  margin,  iii  general. 
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Evaluations  of  TCP/IP  In  a  LAN  Environment 

1.  MITRE  evaluation  reports,  on  TCP  used  In  LAN  configurations, 
Indicated  throughput  capabilities  of  350  kb/s  (4096  bit  message 
size)  and  900  kb/s  In  separate  measurements.  This  formed  a  basis 
for  predicting  a  1  Mb/s  throughput  rate  being  achievable  with  a 
10-Mb/s  Ethernet  LAN. 

2.  A  “discretionary  TCP/IP"  enhancement  approach,  considered  also  by 
MITRE,  Indicated  a  way  to  use  only  LAN  essential  elements  of  full 
WAN-based  protocols,  with  performance  Improvements. 

3.  A  discrete-event  simulation  model  can  provide  a  flexible  tool  for 
the  evaluation  of  an  Integrated  protocol  suite,  layered  together 
In  a  LAN  environment.  While  not  fully  completed,  the  model 
develooed  for  the  study  represented  adequately  the  Ethernet  Blue 
Book  IP,  UOP  and  most  of  the  TCP  functions.  Completion  of  the  TCP 
special  functions,  DOD  higher  layer  protocols  and  Token  Bus/Ring 
LAN  subnets  were  deferred,  In  order  to  conserve  funding  resources. 

4.  The  throughput  attainable  with  ar.  Ethernet  contention  type  LAN 
access  method  were  reduced  as  much  as  50  percent  as  the  loading  or. 
the  cable  varies  from  light  to  heavy  conditions.  In  addition, 
while  one-way  delays  were  low  and  constant  for  light  to  medium 
cable  loadings,  at  around  65  percent  loading  delay  characteristics 
Increased  sharply.  For  maximizing  total  system  throughput  at  the 
cable  reference  point,  very  large  message  sizes  yielded  the  best 
results.  The  reduction  In  throughput  as  loading  was  Increase-*, 
and/or  message  sizes  were  reduced,  was  caused  by  Increasing 
collisions  which  were  produced  ai  the  cable  level.  These  effects 
we»*e  passed  through  upward  to  be  reflected  In  degraded  performance 
of  the  TCP/IP  higher  layer  protocols. 

5.  Throughput  and  delay  performance  of  TCP  and  IP  were  very  sensitive 
to  different  representations  of  Internal  machine  CPU  processing 
speed,  1  ilucpCMUCM  t  of  protocol  overhead.  Faster  CPU  speeds 
yielded  correspondingly  greater  throughput  and  lower  delays.  This 
was  Independent  of  the  effects  of  the  Ethernet  collisions. 
Throughputs  of  0.65  through  5.2  Mb/s  were  demonstrated  for  TCP-TCP 
over  a  single  connection  without  any  collisions,  for  large  message 
size  (Ilk  bits).  The  buildup  of  quaue  size  at  the  TCP  receiving 
station  was  found  to  limit  performance. 


6.  In  multi pi e-noae  multiple-TCP  connection  configurations,  throughput 
for  large  and  small  messages  at  TCP  was  maintained  constant  and 
unaffected  by  total  system  loading  at  the  Ethernet  cable  at  up  to 
65  percent  capacity.  Thereafter,  throughput  decrease  occurred  and 
aelay  increased.  Ethernet  collisions  seemed  to  be  the  cause  of 
this. 

7.  Protocol  overhead,  produced  when  control  header  bits  were  added  to 
the  TCP  client,  or  User  message  sizes,  varied  as  follows: 


TCP  Client  Message  Size 
8  bits,  U 
512  bits,  461 
10,240  bits,  94.5  i 


Combined  Overhead 
991 
541 
5.51 


TCP  Alternatives  for  Intra-LAN  Use 

1.  Three  references  reported  are  alternatives  to  using  the  full  TCP 
for  Intra-LAN  operation.  The  three  selected  other  than  full  TCP; 
one  chose  a  subset,  while  the  other  two  departed  completely  from 


TCP. 

2.  In  one  approach,  a  Local  Network  TCP  was  selected  as  a  compatible 
subset  of  the  WAN  TCP,  based  on  a  philosophy  of  expending 
communication  channel  bandwidth  in  order  to  reduce  protocol 
processing  time.  This  approach  substitutes  for  the  TCP  flow 
control,  resequencing  and  duplicate  detection  features,  and  uses  a 
much  lar  ;er  packet  size  than  In  a  WAN.  Both  the  LNTLP  and  TCP 
would  be  implemented  In  each  LAN  node,  sharing  software  for  the 
same  functions.  This  would  provide  for  efficient  local  Intra-LAN 
performance  while  allowing  for  good  Inter-LAN  (via  WAN)  performance 
as  well . 

3.  An  alternative  to  using  TCP  at  all  took  an  entirely  new  view  to 
intra-LAN  communications,  by  applying  an  extension  to  intra-machine 
backplane  communl cations  in  Its  place.  This  employee  a  transparent 
remote  procedure-call  form  of  message-based  Interprocessor 
communication  in  support  of  a  distributed  operating  system.  This 
method  was  chosen  as  an  alternative  to  using  internetwork  protocols 
on  a  LAN,  which  would  lead  to  minimal  benefits  and  significant 
costs.  To  satisfy  the  ‘teeds  of  distributee  processing  operating 
system  requirements,  the  procedure-call -like  request-response 


7.0  BECOME  NUAT1CNS 

This  section  presents  a  roadmap  plan  In  the  form  of  a  set  of 
recommendations  for  consideration  by  the  Air  Force,  based  upon  the  study's 
conclusions  presented  In  Section  6.0.  The  recommendations  address  tho  following: 

1.  Joint  Mr  Force-Industry  C^I  Applications  and  Protocol 
Development  Effort. 

2.  C^I  Applications  and  Systems  Layered  Reference  Model. 

3 

3.  Generic  Network  Operating  System  (GNGS)  for  C  l. 

4.  Use  of  gateways  and  GWnS  Protocols  for  LAN-based  System 
Interoperability* 

5.  Need  for  different  Intra-LAN  and  Inter-LAN  Protocols  for  Underlying 
Transport  Services. 

6.  Multiple  Industry  Standardized  LAN's  to  meet  Application 
Requirements. 

7.  Continued  research  into  Protocol  Design,  Validation  and  Formal 
Verification  Methods. 

8.  Design  Practices  Handbook  for  Quantifying  LAN  Performance 
characteristics. 

9.  Performance  Evaluation  of  High  Level,  Multiple  LAN's  and  WAN 
Protocols  through  Simulation  and  Modeling. 

10.  Future  Study  in  areas  of:  1)  Distributed  System  Design,  2) 
Integrated  OSI  for  Distributed  Information  Processing  and  3) 

_ Multilevel  Secure  Distributed  Operating  System. _ 

1.  An  Integrated  and  coordinated  joint  Air  Force- Industry  effort  to  developing 
applications  of  distributed  processing,  operating  systems,  data  base  management 
ar.d  networking  prctoccls  for  C-I  Systems  is  recommended. _ 

One  approach  for  consideration,  based  upon  experience  gained  from 
participation  In  the  IEEE  802  LAN  and  SAE  AE-913  High-Speed  Data  Bus  standards 
bodies,  would  be  to  set  up  a  C  I  Architecture  and  Protocols  Development  body  of 
committees  with  appropriate  working  groups.  This  body  would  be  led  by  the  Air 
Force  but  have  active  participation  from  Industry  contractors  and  researchers. 

The  scope  would  Include  policy,  requirements,  applications,  architecture, 
distributed  processing,  distributed  operating  systems,  data  base,  security  and 
networking  protocols  (spanning  all  layers  from  media  through  applications  layers). 

Government  funding  and  IRiD  resources  are  sources  for  supporting 
participation.  Not  only  would  research  and  technology  areas  be  addressed  but  also 
translation  into  finalized  solutions,  designs  and  military  standards/ 
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3 

recommendations  affecting  procurements  for  C  I  programs  would  be  the  real 

3 

output.  Coordination  with  strategic  C  I  and  the  other  tactical  services  would 

2 

be  necessary  to  assure  interoperability  for  C  information  sharing  and  systems 
survivability. 

- - - 

2.  A  layered  architecture  reference  model  for  C  I  systems  and  applications 
development  is  recommended. 

- 3 - 

The  complexity  associated  with  C  I  systems  can  benefit  from  the  use 

of  a  layered  architecture  reference  model.  This  model  would  divide  up  the  major 

C^I  functions  Into  groupings  of  layers  such  that  end  user  applications  reside  at 

the  top  and  physical  resources  reside  at  the  bottom  most.  The  overall  model  would 

3  2 

be  structured  to  identify  C  I  applications,  C  utilities,  data  base  and  the 
Generic  Network  Operating  System  (GNOS)  containing  the  networking  protocol  layer 
regions  (application  layer  through  medium).  The  model  would  be  defined  formally 

3 

in  terms  of  overall  C  I  architecture,  services,  functions,  subsystems, 
interfaces  and  protocols.  Such  a  model  would  be  a  basis  tor  guiding  the  work  of 
the  C  I  Architecture  and  Protocols  Development  body  (Recommendation  1  above). 

3.  A  Generic  Network  Operating  System  (GNOS)  Is  recommended  to  be  defined  for  and 

3 

guide  C-I  systems  developments. _ 

The  heart  of  the  recommended  CJI  Layerea  Architecture  model  is  the 
distributed  global  operating  system  ano  its  suite  of  protocols.  A  proposed  GNOS, 
described  in  Section  5.0,  Results,  and  Appendix  D,  would  provide  an  open,  vendor 

3 

independent  model  ana  formal  definition  to  guide  this  part  of  the  C  I 

3 

architecture.  Since  real  implementations  of  C  I  systems  will  entail  complex 
interoperability  among  heterogeneous  elements  and  end  systems,  GNOS  is  neeaed  to 
exhibit  the  properties  of  an  open  system. 

An  Important  part  of  the  GNOS  will  be  the  mechanism  ana  procedures 
necessary  for  multilevel  security  in  the  networking  environment  and  the  various 
protocols.  Other  important  aspects  are  the  user  Interfaces,  programming 
languages,  an  operating  system  command  and  response  language,  object  to  object 
peer  protocols,  resource  manager  to  resource  manager  peer  protocols,  networking 
utilities  protocols,  host  to  host  and  internetworking  protocols  and  the-  underlying 
LAN's  and  WAN's  protocols  and  gateways.  Section  8.0,  Areas  of  Further  Study, 
discusses  many  of  these  issues  as  do  the  appendices. _ 

4.  Standardized  use  of  generic  gateway  elements  and  open  GNOS  protocols  are 
recommended  as  the  fundamental  approach  to  LAN-based  systems  interoperabi 1 i ty . 


systems  which  will  exist  and  be  used  in  building  C3I  systems.  These  gateway 
elements,  discussed  In  Section  5.0,  Results,  and  further  defined  in  Appendix  F, 
span  from  Interconnecting  mediums  at  the  cable  through  entire  end  systems  at  the 
application  protocol  layer.  A  family  of  gateway  elements  should  be  defined  and 
standardized  for  appropriate  levels  of  Interconnecting. 

Additionally,  It  will  be  through  adherence  to  specific  peer  protocols 
where  Interoperability  will  be  obtained.  These  protocols  should  be  open 
(nonproprietary)  and  exhibit  virtual  canonical  end  to  end  services.  While  the  DOD 
currently  has  a  network  protocol  reference  model,  for  the  longer  term  the 
reference  model  and  protocols  of  the  ISO  are  expected  to  require  supporting,  as 
manufacturers'  machines  and  systems  more  and  more  Internationally  Incorporate 
ISO's  OSI  protocols.  Further,  the  ISO  protocol  development  work  Is  considered  to 
represent  a  far  more  advanced  approach  than  that  of  the  current  0C0  towards 
supporting  distributed  processing  and  distributed  operating  system  services  and 
protocols  along  the  lines  needea  for  C3I  use.  A  global  OSI  systems  approach  Is 
now  under  way  In  the  restructured  work  of  ISO. 

Packaging  of  suites  of  the  high  level  protocols  should  take  account  of 
the  way  IBM  LNA's  Logical  Units  (LU'S)  are  grouped  Into  task  or  er.d  user  oriented 
subsystems.  This  packaging  of  appropriate  elements  of  multiple  protocol  layers 
seems  directly  beneficial  to  a  distributed  operating  systems  architecture  with 
performance  Improvement  resulting  from  “soft  layering". 

As  the  current  000  high  level  protocols  provides  the  more  basic 
services  for  application  usage,  the  richer  set  of  protocols  and  range  of  services 
enhancements  seen  under  development  In  the  ISO  wort  should  be  the  basis  for  C  I 
networking  utility  protocols  and  services.  The  military  C3I  suite  of  protocols 
should  incorporate  the  ISO's  OSI  protocols  as  a  supportable  subset.  Additions  to 

3 

OSI  protocols  should  be  the  goal  for  C  I,  not  total  replacement  from  developing 

closed  protocols  different  from  coimon  OSI  services. _ 

5.  Protocols  for  Intra-LAN  and  Inter-LAN  Transport  through  Subnet  Services  are 
recommended  to  be  separate  and  distinct. _ 

Distributed  processing  and  operating  systems  constructed  on  LAN's  need 
protocols,  In  the  medium  through  transport  layers  of  the  network  reference  model, 
which  have  different  characteristics  from  those  being  employed  today  to 
interconnect  machines  using  a  WAN.  Most  traffic  will  be  for  Intra-LAN  and  less 
for  Inter-LAN  exchanges.  Relay  gateways  and  bridge  gateways  can  be  employed  which 
will  eliminate  the  need  for  Internet  protocols  In  many  Instances.  The  predominant 
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form  of  Interprocess  communications  to  be  employed  appears  to  be  short, 
transaction-based  remote  procedure  calls  for  Inquiry/response.  This  can  be 
provided  by  a  connectionless  {or  data-gram)  service.  However,  a  connection-based 
service  will  also  be  required,  where  streams  of  data  (a  file)  Is  to  be 
transporteo.  This  presents  a  different  form  of  Interprocess  communications  from 
that  exhibited  In  today's  DOD  mandatory  Transmission  Control  Protocol  (TCP). 

in  support  of  this,  the  IEEE  802  LAN  and  ANSI  X3T95  FDDI  protocols  are 
based  upon  requiring  the  connectionless  service  be  mandatory  with  a  connection 
form  optional.  Additionally,  these  inherently  support  single  cast,  multicast  and 
broadcast  forms  of  Intra-LAN  comnunlcatlons.  Robust  connection-oriented  transport 
protocols  should  be  Implemented  In  LAN  to  WAN  gateways  and  provide  the  end  to  end 
reliability  through  that  portion  of  our  Internet.  Translation  from  LAN  to  WAN 
should  be  confined  to  the  gateway  characteristics. 

Further,  in  a  LAN  environment,  protocols  should  be  designed  to  tradeoff 
bandwidth  efficiency  In  order  to  reduce  protocol  processing  times.  With  LAN 
speeds  moving  from  10's  to  100's  of  megabits  per  second,  and  faster  and  cheaper 
microprocessor  and  VLSI/YHSIC  devices,  this  tradeoff  can  produce  even  greater 
performance  In  a  LAN  environment  along  with  a  whole  new  philosophy  for  structuring 
protocols  for  LAN's. 

Development  of  these  protocols  snould  be  done  in  close  cooperation  with 

the  industry  standards  bodies,  such  as  IEEE  802,  SAE/AE-98  and  ANSI  X3T95. _ 

6.  Multiple  Industry  standardized  LAN  types  are  recommended  to  be  employed  for 
matching  applications  requirements. _ _ 

No  single  LAN  will  satisfy  the  diverse  range  of  C  I  requirements.  Gn 
the  other  hand,  LAN's  should  be  employed  where  their  unique  characteristics  are 
superior,  overall.  Use  of  vendor-independent,  nonproprletry,  or  open  LAN's  Is 
suggested.  This  can  be  achieved  by  basing  selection  upon  Industry  standardized 
LAN  protocols.  Currently,  the  IEEE  802  represents  the  10  Mb/s  class  while  the 
ANSI  X3T95  Is  developing  a  100  Mb/s  class.  Other 'organizations  are  known  to  be 
starting  work  in  the  100-1000  Mb/s  class  (SAE-AE9B  Avionics  High-Speed  Lata  Bus). 
Where  lacking  In  services  or  features,  the  Air  Force  should  add  on  to  Industry  LAN 
standards  so  as  to  create  a  compatible  superset.  Maintaining  as  much 
compatibility  with  the  recognized  Industry  standards  will  be  both  equipment  cost- 
effective  as  well  as  enhance  LAN  Interconnectabillty  and  interoperability. 

As  a  good  rule  of  thumb,  the  following  represents  suitable  uses  for  the 
three  leading  LAN  media  access  methods  developed  by  IEEE  802: 
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1.  CSMA/CD  (Ethernet  or  contention  access) 

Smaller  sized  10  Mb/s  LAN's,  where  traffic  loadings  don't  exceed 
about  50-60  percent  and  where  low  or  controlled  maximum  delays  are 
crl tlcal . 

2.  Token  Access  (Deterministic  Access) 

Larger  sized  10  Mb/s  LAN's,  where  traffic  loadings  will  exceed 
50-60  perpent  and  where  low  or  controlled  maximum  delays  are 
critical.  Token  Ring  In  addition  supports  multiple  priorities  and 
a  nix  of  synchronous  and  nonsynchronous  traffic  for  nixing  voice 
and  data. 

3.  Broadband  Coax 

This,  with  Its  Inherent  wide  bandwidth  and  multiplexed 
_ channelization,  supports  voice,  data  and  video  simultaneously. 

7.  Continued  progress  Is  needed  In  the  areas  of  formal  protocol  design, 

validation  and  formal  verification  methods.  It  Is  recommended  to  sponsor  study, 
demonstration  of  methods  ana  development  of  recommended  design  practices,  In 
conjunction  with  work  already  undor  way  In  Industry. _ 

Protocols,  comprising  the  heart  of  a  distributed  processing  system,  are 
crucial  to  Its  proper  operation.  The  asynchronous  and  nondetermlnlstlc  properties 
associated  with  remotely  1 nterconmunl eating  finite  state  machine  processor  and 
systems  leads  to  our  overly  complex  design  and  certification  problem.  Work  has 

already  been  started  on  this  by  Dr.  Carl  Sunshine  and  others  In  ISO  and  CCITT  for 

communications  networking  protocols.  This  needs  to  be  applied  equally  to  ether 
areas  above  the  network  communications  protocol  laye«*s  to  take  account  of  resource 
(object)  manager  and  process  to  proslac  protocols. 

The  Impact  of  VHSIC/VLSI  In  the  Implementation  of  protocol -based 

distributed  operating  systems  needs  to  be  taken  Into  account  as  well. _ 

8.  Quantification  of  LAN  performance  characteristics  and  guideline  design 

practices  for  LAN's  are  recommended.  This  should  en^iloy  combined  analytic, 
simulation  and  measurement  methods. _ 

Engineering  analysis  and  practical  prediction  methods,  needed  for 
understanding,  comparing  and  designing  LAN's,  are  not  readily  available  to 
developers  and  users  of  LAN's.  This  causes  confusion  and  unnecessary  costs,  and 
can  lead  to  making  the  wrong  choice  of  a  LAN  for  an  application. 

Now  that  the  standards  work  of  the  IEEE  802  has  matured  for  CSMA/CD, 
Token  Bus,  Token  Ring  Access  Methods  and  the  common  Logical  Link  Control,  It  would 
be  possible  and  beneficial  to  develop  a  set  of  recommended  design,  analysis  and 
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prediction  practices  covering  all  of  these.  A  combination  of  analysis  simulation 
and  measurement  approaches  is  suggested.  This  needs  to  cover  the  properties 
affecting  throughput,  delay,  topology  sitings,  message  site  variations  and  other 
Important  properties.  Comparison  and  suggested  ranges  for  applications  could  be 
made  as  well.  The  output  of  this  would  produce  a  designer  handbook. _ 

9.  Simulation  and  modeling  effort  for  evaluating  performance  of  high  level, 

multiple  LAN  and  WAN  protocols  for  is  recommended. _ 

The  tan  Interoperability  Study  contract  was  only  able  to  support  the 
completion  of  a  small  portion  of  the  original  objectives  sot  for  the  simulation 
and  modeling  of  LAN-based  protocols  (see  Table  4.8).  This  work  should  be 
continued  to  enable  quantifying  the  performance  of  Integrated  protocols  spanning 
all  layers,  under  the  loading  effects  of  a  distributed  and/or  network  operating 
system  set  of  user  processes. 

The  model  should  add  IEEE  5C2  Token  Bus  and  Token  Ring  access  methods 
as  well  as  take  Into  account  connection-oriented  services  for  the  Logical  Link 
Control,  rull  TCP  and  IP  services  neeo  completing.  Next,  high  level  protocols 
for  terminals,  files,  jobs,  mall  and  name  sender  would  be  added  ana  evaluated. 
Alternatives  for  TCP  and  IP  for  Intra-LAN  operation  should  be  evaluated.  The 
sensitivity  to  varying  processor  speeds  on  protocol  delays  should  be  examined 
further.  The  model  should  then  be  expanded  to  add  an  Internet  between  LAN's  and 
Investigate  Internetworking  effects  and  gateway  operations.  The  findings  should 
be  compiled  and  published  to  assist  developers. _ _ _ _ _ 

10.  Several  additional  technological  areas  of  study  are  recommended  to  be 

supported. _ _ _ _ _  _ _ _ — — 

Section  8.0  Identifies  and  discusses  three  areas  of  future  work.  These 

are  as  follows: 
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a.  Distributed  Systems  Design 

b.  Integrated  Open  Systems  Interconnection  for  Distributed 
Information  Processing 

c.  Multilevel  Secure  Distributed  Operating  System 

In  general,  attendance  at  the  1583  and  1984  Distributed  Systems 
Technology  Exchange  meetings  at  RADC  highllghtea  an  apparent  lack  of  Interstudy 
coordination.  The  areas  reported  on  Included  LAN's,  networking  protocols, 
distributed  operating  systems,  data  base,  knowledge-base  systems,  multilevel 
security  and  multi-media  workstation  technologies.  There  was  lacking  an  overall 
framework,  a  common  systems  architecture  for  tying  these  technologies  together. 
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As  a  result,  there  were  different  assumptions  about  this  "real  problem,"  • 
duplication  of  functions  ano  a  grouping  of  advocates  Into  distinct  camps. 
Recommendations  1-9,  If  Implemented,  would  solve  these  problems. 

The  three  areas  of  future  work  discussed  in  Section  8.9  should  be 
pursued  with  the  above  considerations  In  mind. 
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8.1 


AREAS  OF  FUTURE  WORK 
General 


This  section  presents  a  discussion  on  three  areas  where  future 
technological  Investigative  type  work  Is  needed.  The  three  are  as  foll**s: 

1.  Distributed  System  Design  Issues 

2.  Integrated  Open  Systems  Interconnection  for  Distributed  Information 
Processing 

3.  Multilevel  Secure  Distributed  Operating  System 

While  there  are  many  other  areas  needing  further  study,  loo,  this 
report  focuses  upon  the  three  Identified  ones  because  of  their  relative  Importance. 
8.2  Distributed  System  Design  Issues 

8.2.1  Introduction 

There  are  a  number  of  unresolved  Issues  surrounding  the  subject  of  the 
design  of  distributed  systems.  These  range  from  architectural  Issues  to 
terminology  disputes. 

There  are  at  least  three  types  of  distributed  systems,  which  can  be 
characterized  as  follows  [26.  27]: 

Network  Operating  System  -  a  system  In  which  a  group  of  two  or  more 
host  machines  are  Interconnected  over  a  network  conaunlcations  medium; 
the  hosts  are  loosely  bound  by  the  network  operating  system  (NOS)  which 
manages  the  resources  of  the  distributed  system  In  a  cooperative  way, 
l.e.,  via  request  rather  than  via  directive;  the  user  may  use  the 
resources  of  the  local  hosts  via  Interaction  with  the  local  constituent 
operating  system  (COS),  or  the  resources  of  the  distributed  system  via 
Interaction  with  the  NOS;  the  COS's  may  be  all  of  the  same  type,  e.g., 
all  VAX-11 's  running  VMS,  In  which  case  the  distributed  system  is  known 
as  a  homogeneous  NOS,  or  each  COS  may  be  completely  different,  e.g.,  a 
VAX-11  VMS  two  IBM-PC's,  a  PDP-11/45  RSX-11M  system,  and  an  Apple  PC, 

In  which  case  the  distributed  system  is  known  as  a  heterogeneous  NOS. 
Distributed  Operating  System  -  a  system  in  which  a  group  of  two  or  more 
host  machines  are  interconnected  over  a  network  communications  medium; 
the  hosts  are  under  the  direct  control  of  the  distributed  operating 
system  (DOS),  which  Is  the  only  operating  system  (l.e.,  there  are  no 
COS's);  the  DOS  Is  directive  In  nature,  able  to  issue  explicit 
directives  to  the  host  machines;  while  the  actual  hardware  resources 
may  be  composed  of  identical  or  dissimilar  devices,  the  nature  of  a  DOS 
Is  homogeneous,  since  the  user  Interface  Is  the  DOS,  of  which  there  Is, 
of  course,  only  one. 
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Distributed  Processing  System  -  a  system  In  which  a  group  of  two  or 
■ore  host  machines  are  Interconnected  over  a  network  communications 
■edlum;  the  user  processes  communicate  with  each  other  via  the 
communication  network  protocols,  and  coordinate  >jieir  functions  on  an 
Internal  level;  there  Is,  therefore,  no  distribution  of  operating 
system  functions  or  system  control,  but  this  does  not  preclude  directed 
use  of  distributed  system  resources. 

These  definitions  are  not  universally  accepted.  For  instance,  the 
Cronus  system  [29,30,31]  Is  characterized  as  a  "distributed  operating  system"  in 
Its  support  documentation,  while  using  the  above  definitions.  It  would  be 
classified  as  a  network  operating  system.  Also,  the  characterization  of 
homogeneous  or  heterogeneous  could  be  based  on  the  underlying  hardware  elements, 
rather  than  on  the  local  system  control  software. 

It  Is  possible  to  have  some  hybrid  combination  of  any  of  the  above 
definitions.  For  example,  a  system  in<ght  basically  support  a  DOS  view  for  host 
machines,  but  have  semi -autonomous  terminal  concentrators  to  save  the  DOS  the 
overhead  of  managing  the  Internal  functioning  of  these  devices. 

8.2.2  Overall  Architectural  Model 

8. 2.2.1  Viewing  Resources  as  Objects 

A  flexible  and  powerful  approach  to  defining  the  architecture  of 
distributed  systems  Is  the  object  oriented  approach.  In  this  approach,  all  of  the 
resources  associated  with  a  computer  system  are  represented  as  specific  Instances 
of  a  limited  number  of  object  classes.  Each  class  of  objects  encompasses  a  group 
of  resources  or  entitles  which  share  common  characteristics,  Basic  object  classes 
Include  processes,  files,  and  the  various  types  of  devices.  Each  object  has 

associated  with  It  specific,  well  defined  operations  wnlch  may  be  performed  upon 

or  through  use  of  the  object.  Each  specific  Instance  of  an  object,  such  as  a  user 
data  file,  has  a  name  or  other  Identifying  mechanism,  and  other  components  which 
allow  it  to  interact  with  the  outside  world.  These  may  Include  access  rights 
lists,  specific  action  prevention  authorization  (e.g.,  read-only  access,  etc.), 
performance  limitations  (e.g.,  memory  allocation  limits,  etc.),  and  similar 
descriptive  elements. 

Each  object  Is  associated  with  an  "object  manager"  which  knows  all  the 
details  regarding  use  of  the  object.  The  object  manager  serves  as  the 
Intermediary  between  the  user  of  the  objects  resources  and  the  object  Itself.  The 
object  manager,  therefore,  can  ensure  that  all  of  the  generic  rules  of  the  object 
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class  (e.g.,  printers  can  print,  but  they  dannot  read),  and  the  rules  of  the 
specific  Instance  of  the  object  (e.g.,  onl>  users  X,  Y,  or  Z  can  write  to  this 
file)  are  enforced.  The  operating  system,  et  all  levels,  can  be  thought  of  as  the 
complete  collection  of  object  managers. 

Tne  object  oriented  approach  Is  particularly  useful  In  the  design  of 
distributed  systems.  The  modular  nature  of  the  object  model  provides  a 
flexibility  which  Is  Invaluable  In  distributed  system  Implementation. 

8. 2. 2. 2  Distributed  System  Components 

A  distributed  system  can  be  partitioned  Into  a  number  of  components. 

Including: 

Organic  and  Other  Processes  -  all  users  of  the  system  are  processes; 
any  action  which  the  system  takes  Is  taken  at  the  direction  of  some 
process. 

Programming  and  Data  Manipulation  Languages  -  Including  FORTRAN, 

Pascal,  and  other  languages 

Operating  System  Command  and  Response  Language  (OSCRL)  -  Including 
Interactive  command  language  Interpreters,  and  statements  which  can  be 
embedded  In  language  comnands  (e.g.,  JCL  for  IBM  system',  or  Executive 
Directives  for  DEC  VAX/VMS  and  PDP/RSX-11  systems) 

Communications  Networks  (Including  OSI)  -  the  underlying  communications 
hardware,  software,  and  protocols  used  to  connect  the  local  computer 
systems  Into  a  network 

Distributed  Resource  Control  -  the  remote  resource  management  functions 
of  the  NOS  or  DOS,  or  the  agreed  upon  principals  for  remote  resource 
use  In  distributed  processing  systems 

Local  Resource  Control  -  the  COS  or  local  resource  control  portion  of  a 
DOS 

The  organization  and  function  of  these  components  wl^l,  of  course,  vary 
from  system  to  system.  Not  every  system  will  have  all  of  the  components.  For 
Instance,  a  series  of  automated  data  gathering  stations  operated  under  the  control 
of  a  dedicated  processor  may  not  have  any  programming  and  data  manipulation 
language  resources  available  -  It  may  be  implemented  In  firmware. 


8-3 


208SD/LAN 


8. 2. 2. 3  Relationships  Between  Components 

Figure  8. 2. 2. 3  shows  a  possible  architectural  model  which  can  be  used 
to  discuss  the  relationships  between  the  above  entitles: 
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Figure  8. 2. 2. 3.  An  Architecture  Model  for  Distributed  Processing  Systems 

The  model  describes  the  fact  that  a  computer  system  exists  to  allow  the 
users  (human  and  processes)  to  solve  problems  using  system  resources.  The 
Intermediate  entitles  provide  support  for  these  functions. 

8.2.3  Specific  Design  Issues 

8. 2. 3.1  Applicability  of  the  Types  of  Distributed  Systems 

A  major  distributed  system  design  Issue  involvt  selection  of  the  basic 
architecture  as  described  In  the  definitions  given  at  the  beginning  of  this 
discussion.  Each  of  the  types  of  distributed  systems  has  certain  advantages  and 
disadvantages  which  might  qualify  It  for  use  In  one  application,  while  making  It 
unsuitable  for  another. 

The  NOS  and  DOS  approaches  each  have  a  number  of  system  management 
layers  through  which  to  pass  before  action  Is  taken  with  the  desired  system 
resource.  The  performance  of  a  process  on  an  NOS  system  will  most  likely  be 
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Inferior  to  that  of  a  process  on  a  single  machine  system,  or  a  DOS.  This  Is 
because  an  NOS  will  make  a  request  for  the  desired  service  of  the  COS,  which  will 
then  schedule  the  request  according  to  Its  own  design.  A  DOS  would  have  the 
option  of  Issuing  a  directive  to  the  target  local  syster.  (This  scenario  could  be 
handled  by  giving  all  NOS  requests  the  highest  possible  priority  on  each  of  the 
local  systems.)  In  a  distributed  processing  system,  In  which  there  are  no  system 
management  layers  on  the  level  of  an  NOS  or  DOS,  process  performance  could  be 
optimized,  with  system  flexibility  sacrificed. 

An  advantage  of  an  NOS  Is  the  capability  of  independent  use  of  the 
resources  of  the  local  systems  in  the  event  of  network  failure,  since  each  machine 
will  have  a  fully  autonomous  COS.  It  Is  conceivable  that  a  similar  capability 
juld  be  Implemented  In  a  00S  also.  A  related  Issue  Is  that  by  preserving  the 
independence  of  the  local  COS's.  An  NOS  could  be  Implemented  onto  a  network  of 
existing  systems  with  a  minimum  Impact,  allowing  existing  software  to  run  without 
modification. 

8. 2. 3. 2  System  Security 

In  a  networking  system,  security  Is  particularly  Important  due  to  the 
ability  of  others  to  have  access  to  local  systems  over  the  network.  To  ensure  an 
adequate  security  operation,  system  and  data  security  must  be  a  fundamental  design 
issue.  Tt.e  purpose  of  security  functions  within  any  Information  processing  system 
is  the  protection  of  the  system  resources  from  unauthorized  access  and  use.  In 
some  cases,  tMs  definition  can  be  expanded  to  also  Include  limiting  or  at  least 
identifying  any  damage  done  If  some  unauthorized  user  does  obtain  access  to  system 
resources. 

Access  to  the  system  Is  tie  cornerstone  to  any  security  function. 

Access  control  presents  a  special  problem  In  distributed  systems.  Since  the 
system  Is  specifically  designed  to  share  Information  to  remote  locations,  this  Is 

quite  understandable.  Physical  security  of  the  computer  system  resources  must  be 

■*  * 

maintained  at  all  points  of  the  network.  Should  any  node  of  the  network  fall 
under  the  control  of  an  unauthorized  user,  it  Is  possible  for  that  user  to  attempt 
to  access  resources  anywhere  on  the  network.  Of  concern  In  NOS  and  distributed 
processing  systems  is  the  possibility  that  a  user  may  attempt  to  access  resources 
via  the  local  COS  In  an  attempt  to  avoid  the  distributed  processing  system 
security  functions.  Further  complicating  the  NOS  and  distributed  ps*ocessing 
system  security  function  Is  the  fact  that  heterojeneous  security  policies  may  be 
implemented  on  the  nodes  of  the  system.  System  security  Issues  are  discussed  In 
Paragraph  8.4. 
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8. 2.3.3  User  Interface  and  Operating  System  Command  Response  language  (OSCRL) 

Assuming  the  use  of  a  common  OSCRL  over  the  distributed  system,  the 

user  would  not  notice  a  difference  In  the  Interaction  complexity  between  an  NOS 
and  a  DOS.  There  would.  In  fact,  be  no  difference  between  the  Implementation  of  a 
homogeneous  NOS  and  a  DOS,  while  In  a  heterogeneous  NOS,  the  OSCRL  would  have 
heterogeneous  COS  Interfaces  for  which  to  provide  translation  for.  Of  course,  a 
user  on  a  distributed  processing  system  may  not  have  a  common  OSCRL  at  all, 
depending  on  the  nature  of  the  system. 

From  the  discussion  above.  It  appears  that  the  OSCRL  Is  a  major 
consideration  for  a  distributed  system.  Since  the  OSCRL  Is  the  primary  user 
Interface  to  the  system,  !t  must  be  designed  specifically  to  support  the  desired 
distributed  environment.  In  general.  It  Is  Important  that  the  OSCRL  syntax  not 
rely  upon  any  location  designation  to  access  resources,  since  distribution  of 
processing  activities  Is  a  function  of  the  NOS  or  DOS,  the  details  of  which  are 
undoubtedly  based  In  part  on  dynamic  attributes  of  the  system  unknown  to  the  user 
at  all  times.  Of  course,  the  0S1RL  might  support  a  location  specification 
capability  for  Instances  In  which  the  user  desires  to  define  a  specific  location 
for  an  operation  over  the  network.  The  OSCRL  must  also  be  able  to  support  the 
distributed  system  security  scheme,  with  provisions  made  for  passing  of  passwords 
and  keys,  and  other  security  related  matters. 

It  Is  not  clear  at  this  time  what  format  an  OSCRL  for  distributed 
systems  should  take.  Possibilities  for  the  OSCRL  range  from  a  command  line 
interpreter,  such  as  DEC  DCL,  to  a  sophisticated  Icon  and  pointer  screen,  as  In  a 
number  of  general  market  microcomputer  systems  such  as  Apple  Lisa  and  Macintosh 
systems.  (It  Is  possible  that  such  an  Icon  and  pointer  user  Interface  could  be 
Implemented  as  a  layer  above  a  command  oriented  OSCRL.)  Definite  advantages  exist 
for  either  type  of  system,  again  dependent  upon  the  nature  of  the  application. 

8.2. 3. 4  Programing  and  Data  Manipulation  Languages 

Programming  and  data  manipulation  languages  are  the  primary  medium 
through  which  users  direct  computer  systems.  User  languages  usually  Interact  with 
the  computer  system  through  the  OSCRL  (which  Is  actually  another  language). 
Distributed  processing  presents  a  number  of  challenges  to  programming  and  data 
manipulation  language  users.  Two  problems  which  Immediately  come  to  mind  are 
parallel  processing  and  device  specification. 
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If  a  particular  procedure  can  be  partitioned  Into  portions  which  can 
run  in  p_.  allel  on  different  machines  within  the  distributed  system,  the  time 
required  to  execute  the  procedure  can  be  reduced.  Unfortunately,  the  majority  of 
programming  languages  which  exist  today  do  not  explicitly  support  this  type  of 
operation,  sometimes  called  concurrent  processing.  Parallel  processing  can 
produce  a  number  of  error  conditions  which  must  be  guarded  against.  These  Include 
the  possibility  that  execution  of  one  of  the  concurrent  modules  first  may  produce 
different  results  If  this  module  had  not  been  first.  Another  potential  problem  Is 
the  possibility  that  two  or  more  concurrent  modules  might  end  up  waiting  cn  each 
other  Indefinitely,  resulting  In  a  deadlock  condition.  Languages  which  are 
designed  to  support  concurrent  processing,  such  as  Ada  or  Concurrent  Pascal,  have 
software  constructs  which  are  designed  to  help  prevent  these  occurrences. 

Load  sharing,  a  different  concept  from  concurrent  processing,  can  be 
used  In  distributed  system  applications.  In  a  load  sharing  situation,  when  one 
computer  system  Is  overloaded,  procedures  are  sent  to  other  nodes  In  the 
distributed  system  for  processing. 

Another  problem  Incurred  In  the  use  of  computer  languages  Is  that  of 
device  specification.  Many  languages,  such  as  FORTRAN  require  the  specification 
of  the  target  device  In  Input  and  output  statements.  Consider  the  FORTRAN 
statement: 

WRITE  (6,10)  X 

The  Intent  of  this  statement  Is  to  write  the  value  of  the  variable  "X" 
out  to  device  "6"  according  to  the  format  given  In  statement  number  "10".  While 
the  variable  name  "X"  and  statement  number  “10"  are  program  specific  and 
independent  of  the  machine,  the  device  specification  of  “6"  Is  not  necessarily  the 
proper  device  on  all  systems  within  the  distributed  network. 

In  order  for  processes  to  be  executable  on  any  computer  system  within 
the  network,  langauges  must  either  avoid  such  specifications,  or  the  distributed 
system  must  be  able  to  resolve  these  references.  In  some  cases,  however, 
reference  to  a  specific  device  might  be  desired.  It  Is  possible  that  the 
distributed  system  OSCRL  could  Include  functions  which  would  allow  this  Issue  to 
be  solved  on  a  case-by-case  basis. 

8.2.3, 5  Distribution  Issues 

Function  distribution  presents  a  number  of  issues  which  are  normally 
not  a  consideration  In  single  computer  systems.  One  of  those  is  the  degree  of 
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dispersal.  Processes  within  groups  of  processes,  portions  of  single  processes, 
entire  databases,  and  copies  of  Individual  files  can  be  dispersed  throughout  the 
distributed  environment.  Given  a  five  node  network,  a  file  which  has  a  degree  of 
dispersal  of  100%  would  have  copies  resident  on  all  five  nodes,  while  a  file  of 
degree  60%  would  have  copies  on  only  three  of  the  nodes.  While  dispersal  of  100% 
for  every  process  and  tile  In  the  system  would  ensure  the  maximum  degree  of 
survivability,  this  would  also  be  very  Inefficient.  Each  modification  of  a 
dispersed  file  requires  that  all  copies  of  the  file  be  updated.  The  overhead 
associated  with  maintaining  a  large  number  of  100%  dispersed  files  over  a  large 
distributed  system  Is  obviously  quite  large. 

The  manner  In  which  nodes  are  selected  for  use  as  dispersal  sites  Is 
also  an  Issue.  Dispersal  sites  can  be  selected  at  random,  given  a  specified 
degree  desired.  Alternatively,  preset  sites  for  dispersal  can  be  specified  for 
each  node  in  tie  distributed  system.  Other  possibilities  Include  specification  of 
certain  groups  of  nodes  for  dispersal  of  certain  types  of  processes  or  files, 
specification  of  certain  nodes  to  which  a  given  type  of  process  or  file  Is  NOT  to 
be  dispersed  to,  and  others.  An  Important  system  service  In  regard  to  dispersal 
Is  a  utility  which  can  be  run  to  modify  the  dispersal  algorithm.  For  Instance,  In 
a  battlefield  environment,  you  may  want  to  prevent  the  dispersal  of  files  to  nodes 
In  eminent  danger  of  being  overtaken  by  the  opposing  force. 

Another  Important  Issue  In  distributed  systems  design  Is  the  levels  of 
distribution.  How  many  distributed  systems  will  a  given  computer  system  be 
Involved  In?  It  Is  conceivable  that  any  given  system  will  be  Involved  In 
distributed  systems  which  Involve  other  computer  systems  at  the  same 
organizational  plateau,  and  others  which  are  not.  For  example.  In  the  TAC  C3  DOS 
Study  [23],  a  number  of  processors  are  networked  together  under  the  direction  of  a 
distributed  operating  system  known  as  the  Minldos.  For  upper  echelon  command 
levels,  a  number  of  Minldos  networks  are  networked  together  under  the  cognizance 
of  a  Maxldos,  which  is  layered  on  top  of  the  Minldos.  (The  characterization  of 
these  levels  as  a  DOS  Is  again,  not  according  to  the  definitions  presented  at  the 
beginning  of  this  paper.  The  system  described  in  the  TAC  C3  DOS  Study  would, 
according  to  these  definitions,  be  characterized  as  an  NOS,  since  each  computer 
system  has  Its  own  COS.)  While  the  TAC  study  stops  here,  it  Is  not  unreasonable 
to  envision  a  need  arising  for  additional  or  overlapping  layers  beyond  the  Minldos 
and  Maxldos  networks. 
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8.2.4  Conclusions 

Distributed  system  control  Is  a  very  complex  subject  which  will  require 
a  great  deal  of  further  research  to  become  fully  effective.  The  Inherent 
flexlbllty  of  distributed  systems  will  allow  a  great  diversity  In  the  manner  of 
control  of  distributed  systems.  Just  as  the  specific  type  of  distributed  system 
•/111  vary  from  application  to  application,  so  too  will  the  appropriate  form  of 
distributed  system  control. 

There  are  a  number  of  Issues  and  general  areas  In  this  field  which 
warrant  further  research.  Several  of  these  are: 

•  Potential  uses  of  artificial  Intelligence  (AI)  techniques  for 
network  control  and  security  functions 

•  The  nature  and  design  of  an  appropriate  user  Interface,  both  user 
Interactive  and  process  embedded 

•  Philosophies  and  algorithms  for  degree  of  dispersion  and  similar 
survivability  and  object  update  and  control  Issues 

•  Design  philosophies  and  Issues  Involved  In  multiple  levels  of 
distributed  control  (e.g.,  Mlnldos  and  Maxldos) 

•  System  reliability  and  performance  tradeoff  studies 

a  Distributed  system  security  functions  (In  addition  to  those  studied 
under  the  AI  subject  area) 

•  Centralization  and  decentralization  of  distributed  system  control 

•  System  failure  and  degradation  control,  both  Intentional  and 
unintentional 

•  Distributed  system  topology  and  growth  management  Issues 

This  list  Is  by  no  means  all  Inclusive.  Many  of  these  studies  will 
have  to  be  carried  out  In  light  of  specific  objectives,  since  conclusions  reached 
for  one  type  of  application  may  not  be  suitable  for  others.  For  example,  a  system 
which  required  quick  responses  of  the  user  In  order  to  prevent  unauthorized  and 
untrained  users  to  access  the  system  would  not  be  suitable  for  a  university 
teaching  environment.  As  with  the  evolution  of  COS's,  there  will  be  a 
multiplicity  of  distributed  systems,  some  general  purpose,  others  more 
specifically  tailored  to  a  given  application. 
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Integrated  Open  Systems  Interconnection  for  Distributed  Information 
Fr~6?S55Tng - 

8.3.1  ANSI/OSI  Networking  Committee  Reorganization 

Several  factors  In  the  field  of  computer  networking  ana  distributed 
processing  are  driving  a  reorganization  of  the  ISO  and  ANSI  corral ttees  which  deal 
with  these  and  related  technologies.  Currently,  the  areas  of  computer  networking, 
database  technology,  data  security,  and  operating  system  technology  are  considered 
distinct  and  separate  fields,  each  represented  by  Its  own  committee  or  subcommittee 
In  the  international  and  national  standards  bodies. 

There  Is,  however,  a  growing  consensus  that  with  the  advent  of 
distributed  processing  technology,  the  fields  are  no  longer  distinctly  separate, 
and  therefore  should  not  be  separated  In  standards  committee  deliberations.  The 
trend  is  perhaps  best  summarized  by  Bachman  and  Ross  [16]: 

"The  ISO  Reference  Model  of  Open  Systems  Interconnection  Is  a  major 
tool  of  TC97  for  the  study  and  organizations  of  standards  activities 
relating  to  Interprocess  communications.  The  authors  believe  that  the 
development  of  a  larger  reference  model  to  cover  the  complete  scope  of 
computer-based  information  systems  would  provide  an  even  greater  force 
within  TC97  to  assist  it  In  determining  the  standards  to  be  produced 
and  help  place  existing  standards  Into  a  larger  context." 

The  ISO  OSI  Reference  Model  Is  the  computer  networking  communications  standard 
basis  currently  adopted  by  the  International  community.  These  authors,  and  others 
[15],  are  supporting  the  Idea  that  more  useful  standards  work  could  be 
accomplished  by  considering  this  aspect  of  Information  processing  as  only  a  small 
part  of  a  larger  scheme.  Figure  8.3.1  Illustrates  the  enlarged  model  which 
reference  16  developed  to  focus  the  global  OSI  work  upon. 

These  changes  will  therefore  bring  the  full  weight  of  the  International 
standards  making  organization  to  the  problem  of  fully  distributed  Information 
processing  technology.  It  is  conceivable  that  within  five  to  seven  years,  there 
may  be  fully  adopted  International  standards  to  cover  the  entire  range  of  data 
manipulation,  operating  system  and  command  language  interface,  and  network 
communications  needed  to  support  open  system  distributed  processing. 

8.3. 1.1  ISO  Technical  Committee  97  Reorganization 

OMNICOM,  In  its  July  1984  Open  Systems  Communications  Newsletter  [97], 
reported  on  the  reorganization  of  Technical  Committee  97  along  the  lines  dlscussea 
above.  In  the  manner  which  follows. 
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Figure  8.3.1.  Global  OSI  Reference  Model  of  Computer  Based 
Information  Systems  Functional  Subarchitectures 


"The  International  Organization  for  Standardization  (ISO)  officially 
restructured  Its  Technical  Committee  TC97  on  Information  Processing  Systems  by  an 
action  taken  at  the  TC97  Plenary  Meeting  In  Stockholm,  May  16-18,  1984.  The 
restructuring  had  two  principal  purposes: 

•  To  Improve  the  manageability  of  the  very  large  and  growing  overall 
program  of  work  of  TC97  and  the  relationship  between  TC97  and  other 
ISO  committees  and  international  organizations  (l.e.,  CCITT  and  IEC) 

•  To  Improve  the  coordination  and  liaison  between  major  elements 
within  TC97,  In  particular  the  standards  related  to  the  upper 
layers  of  OSI 

In  addition  to  the  restructuring,  TC97  approved  a  revised  wording  of 
the  definition  of  Its  scope  to  Increase  clarity: 

Standardization,  including  terminology,  In  the  area  of  information 
processing  systems.  Including  but  not  limited  to  personal  computers  and 
office  equipment. 
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lo  Improve  the  manageability  and  planning  of  Its  work  program,  TC97  was 
restructured  Into  three  groupings,  and  a  Ylce  Chair  was  appointed  for  each 
grouping: 

Application  Elements:  Mr.  A.  Tatelshl,  Canada 
Eqyjpment  and  Media:  Proof.  H.  Wada,  Japan 

Systems:  Mr.  Y.  Le  Roux,  France 

The  Vice  Chairs  are  responsible  primarily  for  ensuring  che  coordination  of, 
planning  for,  and  Interaction  among  the  subcommittees  within  their  grouping.  This 
will  promote  better  harmonization  cf  the  standards  developed  within  TC97  and  will 
facilitate  liaison  with  other  organizations. 

The  subcommittees  assigned  to  each  grouping  are: 

Application  Elements: 

SC  1  Vocabulary 

SC  7  Design  and  Documentation  of  Computer  Based  Information  Systems 
SC14  Representation  of  Data  Elements 
Equipment  and  Media: 

SC10  Magnetic  Disks 

SC11  Flexible  Magnetic  Media  for  Digital  Data  Interchange 

SCI 3  Interconnection  of  Equipment 

3d 5  Labeling  and  File  Structure 

SCI 7  Identification  and  Credit  Cards 

SCI 9  Office  Equipment  and  Supplies 

SC23  (new)  Optical  Digital  Data  Disks 

Systems : 

SC  2  Character  Sets  and  Information  Coding 

SC  S  Telecommunications  and  Information  Exchange  between  Systems 
SC18  Text  and  Office  Systems 
SC20  Data  Cryptographic  Techniques 

SC21  (new)  Information  Retrieval,  Transfer  and  Management  for  Open 
Systems  Interconnection 

SC?2  (new)  Application  Systems  Environments  and  Programming  Languages 
The  changes  of  greatest  Interest  to  KIN I COM  subscribers  are  within  the 
Systems  grouping.  These  Induce  changes  to  SC6  and  SClB,  and  the  establishment  of 
the  new  SC21 : 


2085D/LAN 


8-12 


SC6,  Telecommunications  and  Information  Exchange  Setween  Systems 

Transport  Layer  It  added  to  the  scope  of  SC6,  which  Is  now  responsible 
for  the  lower  four  layers  of  OSI:  Physical,  Data  Link,  Network,  and  Transport. 

This  makes  for  a  very  clean  Interface  between  the  work  of  SC6  and  that  of  SC21, 
which  has  Session  Layer  and  above:  SC6  provides  all  end-to-end  “bit  pipes",  and 
SC?1  provides  for  the  standardized  use  of  the  bit  pipes  to  transfer  Information 
across  the  OSI  environment. 

SC18,  Text  and  Office  Systems 

Text  Preparation  and  Interchange  Equipment,  and  Computer  Language  for 
the  Processing  of  Text,  are  added  to  the  scope  of  SC18,.  which  Is  now  responsible 
not  only  for  the  functional  and  structural  standards  for  text  preparation  and 
Interchange  (l.e.,  terminology,  document  architecture,  text  processing  functions, 
text  layout,  and  document  Interchange),  but  also  for  specialized  terminal  equipment 
standards  and  programming  languages  required  in  this  area.  This  Is  consistent 
with  the  Increased  application  emphasis  o*  the  TC97  restructuring.  Intended  to 
provide  better  responsiveness  of  the  ISO  TC97  standards  to  the  application  areas 
for  which  the  standards  are  being  developed. 

SC21 ,  Information  Retrieval,  Transfer  and  Management  for  Open  Systems 

Interconnection 

A  major  new  subcommittee  has  been  formed  out  of  major  sections  of  the 
old  SC5,  Programming  Languages,  and  SC16,  Open  Systems  Interconnection.  SC21  Is 
responsible  for  the  Session  Layer  anu  above  of  OSI,  together  with  computer 
graphics,  database,  and  operating  systems  command  and  response  languages.  This 
puts  into  one  subcommittee  all  standards  related  to  "virtual  Information 
resour.es:"  terminal  functions,  graphics,  database,  files,  OSI,  and  operating 
systems  services.  This  should  make  It  far  easier  to  develop  and  maintain 
compatibility  among  all  these  "upper  layer  standards." 

8.3,2  Integrated  OSI  for  Distributed  Information  Processing 

Combining  Communications  with  Programming  Languages,  Data  Base  and 
Operating  System  Command  Response  Language  (OSCRL)  projects  will  require  work  on 
Open  Systems  Interconnection  for  total  information  processing  (Figure  8.3.1)  in 
the  context  of  a  larger  reference  model.  The  new  enlargeo  model  would  cover  the 
complete  scope  of  distributed  computer-based  Information  systems  integrating  the 
layered  architectures  for  data  storage/retrleval  as  well  as  for  Interprocess 
communications  and  systems  management.  A  common  Information  presentations  layer 
would  provide  syntax  representations  fo**:  1)  Interprocess  communications,  2)  data 

storage  and  retrieval,  and  3)  operations  on  the  data  local  to  the  process. 
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The  global  OSI/RM  view  In  Figure  8.3.1  Identifies  a  new  layer  for 
Application  Management  functions,  that  are  not  application  type  specific,  which 
deal  with  process  integrity  and  security,  called  Process,  Transaction  and  Resource 
Management  (P,  T'  and  RM  Layer).  Above  the  P,  T  and  RM  layer,  would  be  the 
Applications  Specific  layer  entitles,  while  above  them  would  be  Software  Program 
Support  and  Systems  Management.  Beneath  the  P,  T  and  P.M  layer,  would  be  the 
interprocess  communications  and  the  data  storage  and  retrieval  subsystems  of 
layered  protocols. 

High  level  protocols  for  networks  may  become  defined  in  terms  of  data 
types  where  applications  protocols  would  be  defined  In  terms  of  the  universe  of 
discourse  appropriate  to  the  distributed  application;  if  so,  then  programming 
languages  having  strong  data  typing  will  be  important. 

The  Air  Force  needs  to  participate  In  the  above  discussed  projects  In 
order  to  benefit  more  effectively  from  the  resultant  protocols  and  other  standards. 

8.3.3  Issues  Associated  with  an  Integrated  QSI  for  Distributed  Information 

Processing 

1.  A  common  universe  of  discourse  is  required  between  cooperating 
application  processes  (same  semantic  Interpretation  of  Information 
exchanged). 

2.  Commitment  and  recovery  protocols  are  required  In  application  layer. 

3.  Distributed  open  systems  need  a  common  (standard)  form  of  an 
"Operating  System  Command  and  Response  Language  (OSCRL)"  meeting 
the  common  requirements  of  ill  operating  systems, 

4.  OSCRL  needs  to  adopt  the  characteristics  of  a  real-time,  parallel 
programming  language  to  function  in  a  distributed  environment;  Its 
data  objects  become  abstract  objects  specifying  characteristics  of 
Information  processing  resources: 

Processing  time,  work  space,  data  storage.  Input/output 
devices,  communication  channels  and  their  costs. 

5.  OSCRL  Initiated  activities  In  OSI  will  be  subject  to  both 
processing  delay  and  communications  delay  and  necessitate  the 
ability  to  handle  not  only  these  delays  but  recoveries  from 
failures. 

6.  OSCRL  should  satisfy  both  machine  as  well  as  human  user  needs. 

7.  OSCRL  needs  t;  be  concerned  not  only  with  job  processing  but  with 
file  and  data  handling  resources  as  well. 
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8.  OSCRL  will  also  be  concerned  with  the  management  aspects  associated 
with  coordination  of  Application-Process-Group  operations  In 
conjunction  with  OSI  management  protocol  s/functions. 

8.4  Multilevel  Secure  Distributed  Operating  System 

8.4.1  Introduction 

;e  multilevel -secure  DOS  must  meet  stringent  requirements  defined 
by  the  Civ  ..mijiuter  Security  Center;  specifically  those  of  the  "A1  class.-  Class 
A1  demands  a  number  of  functional  capabilities  In  security  policy  and 
accountability.  Its  unique  feature,  however,  is  the  degree  of  assurance  that  must 
be  provided,  much  of  It  through  a  strict  formal  and  mathematical  methodology. 

Fundamental  security  requirements  for  a  distributed  system  - 
authentication,  secrecy.  Integrity  and  necessity  -  are  no  different  from  those  for 
any  other  secu»*e  system  environment.  However,  certain  aspects  of  a  distributed 
system  present  special  problems,  notably:  distribution  of  resources,  sharing  of 
resources,  distribution  of  control,  hetereogyneous  host  processors,  and 
Interaction  between  possibly  different  policy  domains. 

There  are  two  commonly  discussed  types  of  system  that  fit  the  Enslow 
[26]  definition  of  a  "fully  distributed  processing  system": 

•  Systems  In  which  hosts  are  essentially  Identical  and  run  a 
homogeneous  set  of  distributed  operating  system  (DOS)  software  to 
provide  all  functions  and  services. 

•  Systems  In  which  heterogeneous  constituent  operating  systems  (COS) 
are  Interconnected  by  a  global  DOS  (sometimes  called  a  "network 
operating  system"  or  NOS)  that  provides,  despite  the  heterogeneity, 
a  uniform  global  Interface,  global  cbject  access,  symbolic  naming, 
and  other  components  of  system-wide  "transparency". 

Current  Implemented  security  policy  criteria  do  not  address  the  above 
issues.  A  first  result,  then.  Is  that  either  clarification  of  existing  criteria 
or  generation  of  new  criteria  Is  needed.  Each  specific  function  or  service  sought 
for  a  secure  DOS  must  be  examined  In  the  light  of  security  rules  and  objectives 
and  either  allowed,  disallowed,  or  changed.  In  the  process,  some  of  the  security 
criteria  may  change  as  well. 

Given  a  policy  that  Is  applicable  and  sufficient  to  the  DOS 
environment,  we  still  face  a  number  of  design  and  implementation  Issues.  Some 
examples  follow. 

•  How  are  distributed  resources  and  their  control  partitioned? 

e  How  are  labels  maintained  and  secrecy  requirements  enforced  across 

heterogeneous  hosts? 
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•  How  is  message  delivery  assured? 

•  How  are  distributed  data  and  processes  synchronized? 

•  How  are  resource  deadlocks  detected  and  resolved? 

•  How  can  we  be  sure  that  our  design  will  support  growth  In 
applications,  users,  and  equipment? 

Additionally,  the  Impact  of  solutions  to  these  Issues  needs  to  be 
considered  In  full  view  of  DOS  performance  requirements. 

8.4.2  CRONUS  DOS  Baseline 

A  guiding  principle  behind  CRONUS  [29,  30,  31]  Is  computer  system 
Interoperability  within  a  LAN-based  network  of  heterogeneous  host  computers, 
operating  systems,  and  devices.  In  CRONUS  terminology,  this  network  Is  called  a 
cluster  built  on  top  of  a  local  area  network.  Despite  the  wide  mix  of  machines 
ar.d  constituent  systems,  the  user  Is  to  see  a  single  coherent  DOS  providing  a 
range  of  transparent  global  services.  These  Include:  global  system  object 
definition,  access  control  and  protection  of  data  and  resources.  Interprocess 
communication,  distributed  file  management,  a  uniform  mail  service,  and  a  network 
virtual  terminal  capability.  Figure  8. 4. 2-1  Illustrates  the  single  user  view  of 
the  CRONUS  DOS  architecture.  The  multiuser  view  Is  given  In  Figure  8. 4. 2-2. 

The  CRONUS  cluster  enables  autonomous  heterogeneous  machines  to  perform 
operations  under  distributed  control  as  though  they  were  In  fact  a  single  large 
machine.  The  global  reference  “window,"  the  Common  Command  Language  (CCL),  does 
not,  however,  surrender  the  host  machine's  Independence  or  autonomy. 

In  addition  to  providing  transparent  interoperability  (coherence  and 
uniformity),  CRONUS  provides  benefits  directed  at  other  specific  design  goals: 
system  integrity  and  survivability,  assuring  operational  continuity  despite 
component  failures;  scalability  In  addressing  and  configuration;  global  resource 
management  by  task  priority;  component  substitution  capability;  and  support  for 


simplified  system  operation  and  maintenance. 

’’^••^yhlle  the  CRONUS  baseline  provides  concepts  that  are  readily  carried 
over  to  a  secure^>^irment,  the  Inherent  flexibility  of  the  system  may  Introduce 
potential  theoretical  andprS^^Al^problems.  Indeed,  certain  CRONUS  elements  may 

be  fundamentally  unsuited  to  a  secure  'sy!Tj«Ti  design. 

*s. 

The  CRONUS  user  process,  system  prcies^es,  device  and  other  resource 
managers  are  Interconnected  by  iv.eans  of  an  1nterproce$>^£r1nter-object} 
communications  network.  From  a  logical  perspective,  tills  comiiur1Tce»UAtl  Is  by  way 
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Figure  9. 4. 2-1.  Single  User  CRONUS  DOS  Architecture 
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Figure  8. 4. 2-2.  Multiuser  Distributed  CRONUS  System  Environment 
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of  peer-to-peer  protocols.  Procedural ly.  Interprocess  messages  are  composed  with 
the  Idea  of  the  message  structure  library  and  sent  through  the  operation  switch. 
Note  that  the  constituent  operating  system  (COS)  Is  responsible  for  the  direct 
control  of  local  resources  (device  drivers,  etc.).  It  also  shares  aspects  of 
operation  of  a  number  of  the  distributed  functions. 

CRONUS  manages  the  global  resources  of  the  system  through  an 
object-based  model  In  which  "object"  is  an  abstraction  of  the  resource,  to  be 
acted  on  by  a  well-defined  set  of  operations.  CRONUS  objects  have  unique  names 
that  the  user  refers  to  without  knowing  or  needing  to  know  either  the  physical 
resource  involved  or  the  location  of  the  manager  for  the  object.  All  system 
interactions  can  be  described  by  well-defined  object  operations. 

From  a  security  standpoint,  a  design  based  on  abstract  object  and  on  a 
CRONUS  or  CRONUS-1  Ike  object  management  model  can  not  only  provide  efficient 
global  handling  of  resources,  but  can  also  strengthen  resource  Isolation  and  can 
support  an  almost  unlimited  richness  of  object  access  controls.  And  In  fact,  each 
instance  of  a  CRONUS  object  has,  with  a  unique  identifier  (UID),  an  object 
descriptor  that  defines  properties  Including  access  rights. 

Among  the  more  troublesome  areas  in  at-empting  to  define  a  secure  DOS 
are  the  following: 

•  The  very  fact  of  direct  terminal  user  access  to  a  host  constituent 
operating  system  can.  If  not  controlled  In  a  specific,  secure  way, 
compromise  CRONUS  DOS  facilities  that  rely  on  the  host. 

•  CRONUS  access  control  lists,  a  part  of  the  object  descriptor  and 
serving  to  prevent  unauthorized  use  of  objects  and  rescurces  on  the 
system,  are  not  themselves  secure. 

t  User  Identification  of  objects  and  the  permanent  user  data  ba*e 
constructs  suffer  from  a  similar  vulnerability. 

•  The  operation  switch  supports  migratory  and  replicated  objects, 
such  as  files  and  processes;  these  objects  are  moved  by  the  CRONUS 
system  from  nost  to  host  in  an  Insecure  fashion. 

•  Concurrency  control  Is  implemented  In  such  a  way  that  multlole 
copies  of  Identically  named  data  may  be  present  in  the  system  at 
the  same  time.  This  can  lead  to  evident  security  comprc  ise. 

These  problem  elements  can  perhaps  all  be  redesigned  for  a  secure 
distributed  operating  system  without  losing  their  essential  functional 
characteristics  (from  a  user  viewpoint).  However,  it  may  be  Impractical,  If  not 
Impossible,  to  secure  these  elements  using  the  band-aid  (patched)  approach  of 
modifying  the  actual  CRONUS  implementation. 
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An  Important  principle  in  computer-based  security  Is  that  the  central 
protecting  mechanism  (or  complex  of  mechanisms)  must  reflect  a  unified  design;  it 
cannot  be  “patched"  Into  an  existing  Implementation.  Nonetheless,  existing  or 
proposed  systems  have  capabilities  that  would  or  should  be  preserved  In  a  secure 
Implementation.  Among  these  are: 

e  Uniformity  of  procedures  for  using  local  and  remote  resources 
e  Transparency  of  heterogeneous  host  eccentricities 
•  User  access  capabilities  and  limitations 
e  Enhanced  reliability  vis-a-vis  single  host  operation 
It  Is  desirable  to  retain  as  much  of  this  functionality  as  possible.  A 
secure  00S  is  not,  however,  a  patched  up  Insecure  DOS  -  It  cannot  be  and  still 
accomplish  the  unified  protection  required  by  the  Al-system  rules.  But  the 
capabilities  can  be  mapp>  i  clearly  from  the  existing  design  to  a  conceptual 
overview  of  what  a  secure  DOS  must  lock  like. 

Further  work  needs  to  be  undertaken  which  examines  the  abovu  minimally 
identified  Issues. 
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APPENDICES 

This  provides  two  groups  of  appendices  to  the  report.  One  group 
consists  of  working  papers  which  focus  on  protocol  and  design  Issues  needing 
attention  for  LAN  Interoperability.  The  second  group  consists  of  additional 
working  papers  which  focus  cn  Issues  and  design  approaches  to  Internetworking. 

Group  1  Appendices  -  Protocols  and  Issues 

A.  Evaluation  of  00D  Higher  Layer  Protocols 

B.  Some  Improvements  to  DOb  Higher  Layer  Protocols 

C.  Transmission  Control  Protocol  (TCP)  Usage  for  LANs 

0.  Protocols  for  the  Generic  Network  Operating  System  (GNOS) 

E.  Networking  and  System  Resource  Management  Protocols 

F.  Remote  Data  Base  Access  Protocol 

Group  2  Appendices  -  Design  Approaches  to  Internetworking 

G.  Generic  Gateways  for  LAN  Interoperability 

H.  Multi-Media  LAN  (MMLAN)  Internetworking 
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APPENDIX  A  -  EVALUATION  OF  DOO  HIGHER  LAYER  PROTOCOLS 
A.l  POD  and  OSI  Protocol  Reference  Models 

A  layered  protocol  architecture  provides  a  hierarchy  of  control  by 
functionally  decomposing  overall  network  communication  objectives  Into  strata. 

Each  stratum,  or  protocol  layer.  Is  supposed  to  perform  a  particular  function. 
Starting  at  the  lowest  layer,  the  services  of  each  succeeding  layer  are  available 
to  the  layers  above  and  are  built  upon  the  layers  beneath.  The  functionality  of  a 
layer  in  no  way  Implies  an  Implementation  scheme.  Layered  architecture  allows  the 
protocol  designer  the  freedom  to  implement  the  function  according  to  the 
particular  environment  and  requirements. 

Figure  A.l  Is  a  simplistic  representation  of  the  DOO  and  OSI  layered 
protocol  architectural  models.  An  Immediate  observation  is  that  the  functional 
decomposition  of  both  is  the  same  through  the  transport  layer.  It  is  only  at  the 
higher  layers  that  differences  appear. 

The  reason  .for  this  could  be  that  the  functional  basis  for  the 
decomposition  changes  at  this  point.  Through  the  transport  layer  all  layer 
objectives  are  concerned  solely  with  the  transportation  of  data.  A  protocol  above 
this  layer  need  not  be  concerned  with  physical  transmission,  routing.  Involvement 
or  existence  of  Intervening  nodes,  or  errors  detected  and  recoveries  made. 

Instead,  above  the  transport  layer,  the  objective  Is  the  accomplishment  of  a 
particular  task.  Both  the  OSI  and  COD  models  concern  themselves  with  this  overall 
goal,  namely,  the  ability  to  achieve  a  comnon  (distributed)  task. 

Recognition  of  a  functional  transition  above  the  transport  layer  Is 
important.  It  forces  a  change  of  perspective.  The  higher  layer  protocols  look 
downward  to  the  transport  and  lower  layers  only  for  the  data  transmission  serviced 
necessary  for  the  accomplishment  of  their  distributed  tasks.  At  these  higher 
layers  there  is  less  of  a  stratification  of  functions.  Instead,  (and  particularly 
as  viewed  In  the  DOD  model)  there  appear  to  be  groupings  of  decidedly  different 
functions  within  the  same  layer.  This  Is  because  of  the  common  need  for  data 
transmission  services  but  the  differing  purposes  of  tasks. 

An  example  of  this  type  of  functional  transition  can  be  found  in  our 
postal  system.  Here  the  mailbox  acts  as  the  Interface  between  the  data 
transportation  layers  and  the  task  oriented  layers.  Contents  of  mailed  letters 
C'*-'  be  viewed  as  task  data.  A  person  nailing  a  letter  is  not  concerned  with  the 
method  of  transportation,  be  It  truck,  train,  or  plane.  The  concern  is  only  that 
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the  .letter  arrive  at  Its  destination  In  some  reasonable  length  of  time.  This  Is 
t.i*  service  upon  which  the  mailer  depends.  In  turn,  the  postal  department  has  no 
knowledge  of  the  contents  of  letters  ("tasks'),  be  they  bills.  Invitations  or 
correspondence. 

A. 2  Recommended  Approach 

Figure  A. 2  Is  a  representation  of  the  recommended  approach  to  viewing 
protocols  at  the  higher  layers.  It  Is  based  on  the  contention  that  a  different 
functional  perspective  Is  required  above  the  transport  layer.  Viewing  high  layer 
protocol'.  In  this  way  more  closely  parallels  the  real  world  of  distributed 
Information  processing  tasks.  Rather  than  having  each  layer  above  the  transport 
layer  represent  a  single  function.  Instead  these  layers  represent  families  of 
protocols.  These  protocol  families  represent  requirements  for  specific  task 
operations.  Let  the  application  Itself  (or  the  user)  decide  what  class  of 
underlying  data  transport  service  Is  necessary,  the  basic  choice  being  between 
connection  or  connectionless  support.  This  approach  has  been  the  basis  of  the  IBM 
SNA  Logical  Unit  (LU)  architectural  element.  Each  Lli  Is  a  tailored  grouping  of 
protocol  subsets  from  its  Layers  4-7. 
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Figure  A.2.  Recommended  DOD  Layered  Architecture  Model 
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APPENDIX  B  -  SOME  IMPROVEMENTS  TO  THE  DOD  HIGHER  LAYER  PROTOCOLS 
B.l  TELNET  -  Virtual  Terminal  Protocol 

TELNET  is  a  bidirectional,  byte  oriented  communications  facility  for 
termlnal-to-prccess,  terminal -to-terminal ,  and  process-to-process  communications. 
It  is  based  upon  a  scroll  mode  ASCII  TTY.  The  protocol  defines  options  which  are 
negotiated  between  parties  based  upon  the  characteristics  of  local  devices  mapped 
to  a  canonical  network  virtual  terminal. 

As  the  protocol  now  stands  it  does  not  provide  the  capabilities  for 
proper  utilization  of  bit-mapped  displays.  There  are  currently  many  such  devices 
in  service.  The  total  facilities  of  these  high  resolution  displays,  such  as 
windowing  or  font  selection,  are  not  served  by  TELNET. 

One  approach,  which  was  taken  by  the  Terminal -to-Host  protocol,  THP,  is 
to  define  classes  of  terminals.  THP  defined  four  classes  of  terminals:  1)  basic, 
2)  scroll,  3)  paged  and  4)  forms.  By  dividing  terminals  Into  classes  a  virtual 
terminal  mapping  can  be  made  which  provides  a  better  balance  between  being  overly 
restrictive  and  overly  Inclusive.  A  class  could  be  established  for  the  latest 
generation  of  terminals  and  could  provide  a  mechanism  to  allow  for  future 
technological  growth.  The  problem  Is  a  very  complex  one  but  one  whose  resolution 
is  called  for  as  soon  as  possible. 

B.2  File  Transfer  Protocol  -  FTP 

The  objective  of  the  File  Transfer  Protocol,  FTP,  is  to  promote  file 
sharing  and  encourage  the  use  of  remote  computers  while  shielding  the  user  from 
variations  In  file  storage  systems.  The  protocol  is  based  upon  a  TELNET 
connection. 

The  TELNET  connection  is  used  to  specify  the  parameters  for  the  data 
connection  (such  as  data  port,  transfer  mode,  representation  type,  and  file 
structure)  and  to  specify  file  system  operations  (such  as  store,  retrieve,  append, 
delete).  The  FTP  transmission  modes  are  stream,  block,  and  compressed. 

The  FTP  is  limited  in  its  ability  to  allow  for  the  variations  which 
exist  between  processors  in  number  representation  and  word  length.  This  is 
especially  noticeable  in  floating  point  number  representation.  It  is  the  intent 
of  the  FTP  that  data  transformations  beyond  those  limited  ones  which  are  provided 
be  performed  directly  by  the  user.  As  such  FTP  does  not  include  many  built  in 
facilities  for  file  transfers  between  diverse  equipments. 
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Some  file  transfer  problems  are  specialized  In  nature,  such  as  the  high 
speed  movement  of  extremely  large  volumes  of  data.  These  problems  might  be  best 
addressed  by  defining  new  protocols  for  unique  file  transfer  applications.  Aside 
from  specialized  file  transfer  protocols,  more  thought  needs  to  be  directed 
towards  a  file  transfer  protocol  which  does  not  require  so  many  user  supplied 
functions.  For  Instance,  It  may  be  possible  to  Include  type  information  within 
the  block  transfer  mode  header. 

8.3  Internet  Name  Server 

This  protocol,  given  a  name  string,  returns  the  complete  32 -bit 
Internet  address  as  used  by  the  Internet  Protocol  (IP).  The  name  string  Is 
divided  Into  a  network  portion  and  a  host  name  portion.  Tne  protocol  works 
adequately  when  there  are  relatively  few  networks  and  names.  As  more  networks 
become  Interconnected  a  centralized  name  server  becomes  less  desirable  and  a  truly 
distributed  name  server  becomes  necessary.  Also  undesirable  Is  the  fact  that  a 
centralized  name  server  creates  a  single  failure  point. 

A  universal  network  addressing  scheme,  although  for  the  most  part 
considered  highly  unlikely  to  occur,  would  be  extremely  beneficial.  The  telephone 
industry  In  this  country  adopted  a  universal  numbering  plan  (area  code  -  exchange 
-  subscriber  #)  whose  Implementation  Initially  caused  quite  a  conmotlon.  Now  we 
cannot  Imagine  what  telephone  service  would  be  like  If  this  plan  had  not  been 
adopted. 

A  distributed  name  server  protocol  should  also  include  facilities  for 
adding,  deleting  or  changing  Internet  addresses  of  networks  and  nodes.  Also  not 
to  be  forgotten  Is  the  addressing  problem  created  by  mobile  hosts  which  can  move 
from  network  to  network. 
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APPENOIX  C  -  TRANSMISSION  CONTROL  PROTOCOL  (TCP)  USAGE  FOR  LANS 
C.l  A  Case  Against  TCP 

Few  people  would  question  the  fact  that  the  DOO's  Transmission  Control 
Protocol  (TCP)  Is  the  most  robust  and  thoroughly  tested  transport  layer  protocol 
currently  being  used  across  networks.  In  an  Internetwork  environment  where 
end-to-end  reliability  and  absolute  assurance  of  data  delivery  Is  essential  a 
protocol  such  as  TCP  must  be  used.  There  remains,  however,  the  question  of  TCP's 
suitability  for  Intra  LAN  traffic. 

The  vast  majority  of  traffic  within  a  LAN  is  destined  for  another  node 
(or  nodes)  within  that  LAN.  That  Is  what  a  LAN  is  all  about,  the  sharing  of 
resources  and  data  In  order  to  accomplish  -elated  objectives  (distributed  tasks). 
Aside  from  these  related  objectives  LANs  may  be  distinguished  from  one  another 
according  to  topology,  access  scheme,  data  rate,  and  types  of  equipments  which  may 
be  connected  to  them.  The  choice  of  a  LAN  Is  based  upon  how  well  a  combination  of 
these  variables,  as  exemplified  In  a  specific  LAN  product,  fulfill  the  overall 
objectives  of  the  user.  There  Is  usually  some  conscious  evaluation  of  how 
difficult  or  feasible  Internetting  would  be,  but  although  a  LAN  may  be  rejected 
because  of  Its  Inability  to  Internet  It  Is  not  primarily  chosen  for  this  reason. 
The  primary  goal  In  LAN  selection  Is  to  determine  how  well  a  LAN  suits  the 
specific  application  level  requirements  of  Its  client  users. 

This  leads  to  a  myriad  of  LAN  products  each  based  upon  different 
concepts  and  having  different  capabilities.  It  is  p.eclsely  this  diversity  (which 
Is  desirable  from  the  selector's  standpoint)  that  makes  the  wisdom  of  the  forced 
Inclusion  of  TCP  within  all  LANs  which  Internet  or  have  the  potential  of 
Internetting  questionable. 

For  Instance,  many  LANs  possess  the  characteristic  of  extremely  low 
error  rates.  For  these  LANs,  Is  It  really  good  engineering  to  Include  a  protocol 
In  the  suite  for  Intra  LAN  traffic  which  numbers  and  accounts  for  every  byte  of 
data?  Is  a  resequencing  function  (as  required  by  TCP)  necessary  when  there  Is  a 
low  probability  that  messages  can  be  received  out  of  order?  Would  simpler 
retransmission  schemes  suffice  rather  than  the  complex  TCP  procedure? 

Put  simply,  when  an  underlying  network  service  Is  reliable,  as  Is  the 
case  in  the  majority  of  LANs,  a  protocol  like  TCP  is  not  necessary.  To  Include  It 
in  these  cases  violates  a  basic  tenet  of  good  design.  That  tenet  Is:  “Do  not 
provide  functions  which  are  unnecessary,  which  repeat  functions  already  performed, 
or  which  are  superfluous  to  the  accomplishment  of  the  design  goal." 
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Another  argument  against  the  Inclusion  of  the  TCP  for  intra  LAN  traffic 
is  that  it  can  subtract  from  the  performance  of  LAM  special  features.  These 
special  features,  such  as  broadcasting  and  multicasting,  may  have  been  a  criteria 
for  the  original  selection  of  the  LAM. 

Still  another  argument  against  TCP  In  LANs  Is  the  amount  of  resources 
and  computational  overhead  It.  uses.  The  overhead  TCP  incurs  degrades  the  overall 
performance  of  the  LAN.  This  argument  has  already  been  demonstrated.  However,  as 
processors  become  faster  and  as  (virtual)  memory  size  Increases  this  argument 
tends  to  dissolve. 

The  conclusion  is  that  TCP  Is  absolutely  essential  when  Internetting 
but  it  Is  generally  Inappropriate  for  Intra  LAM  traffic. 

C.2  Alternatives 

Clifford  Warner  in  his  article,  “Connecting  Local  Networks  to  Long 
Haul  Networks:  Issues  In  Protocol  Design  (4)“,  has  suggested  four  alternatives. 
These  are: 

1.  Make  all  LAN  nodes  Implement  and  use  TCP  for  all  traffic. 

2.  Implement  two  different  host-to-host  protocols,  TCP  and  a  separate 
network  protocol , 

3.  Place  TCP  at  gateway  nodes  only  and  provide  for  protocol 
translation  there. 

4.  Implement  a  local  host-to-host  protocol  which  maintains  TCP 
features  but  which  is  streamlined  for  LANs. 

Alternative  1  has  already  been  discussed  and  its  disadvantages 
delineated.  Alternative  2  may  yield  good  performance  but  initial  development 
costs  would  be  great.  Additionally,  each  node  would  become  more  complex  with  the 
inclusion  of  two  transport  protocols.  This  could  lead  to  design  complications  and 
maintenance  problems.  Alternatives  3  and  4  thus  remain  as  possible  candidate 
solutions. 

C.3  The  LNTCP  Approach 

Mr.  Warner  calls  the  modified  version  of  TCP  In  alternative  4  a  Local 
Network  Transmission  Control  Protocol  (LNTCP).  The  LNTCP  can  be  thought  of  as  a 
protocol  which  performs  a  subset  of  the  TCP  functions.  This  subset  equates  to  the 
major  TCP  features.  Thus  translation  to  a  fully  Implemented  TCP  at  the  gateway 
node  is  simplified. 
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To  facilitate  th#  translation  tl)e  mapping  of  tha  field  definitions 
which  are  common  to  both  the  LNTCP  header  and  the  TCP  header  should  be  close  to 
Identical.  Figure  C.3  shows  the  TCP  header  and  the  TCP  Psuedo  header.  The  fields 
which  are  shaded  Indicate  the  most  likely  candidates  for  coeaonallty.  TCP  fields 
such  as  the  window,  checksum  and  some  of  the  control  bits  represent  the  more 
complex  procedures  of  TCP.  They  would  probably  not  be  necessary  In  a  local 
network  protocol.  If  any  special  parameters  were  required  by  the  LNTCP  It  is 
possible  that  they  could  be  defined  as  an  option  and  be  carried  along  In  the  TCP 
header. 

The  Idea  of  an  LNTCP  may  at  first  seem  to  be  a  reasonable  approach 
because  of  the  translation  simplicity*  However,  upon  further  examination,  the 
forced  conformity  of  an  LNTCP  to  TCP  features  may  not  be  at  all  pra  tical  In  a 
real,  operational  environment.  The  worst  proDlem  with  this  approach  is  the  tight 
coupling  of  the  LNTCP  to  the  TCP.  It  emphasizes  the  Inter-relationship  these 
two  protocols  and  as  such  Is  an  undesirable  design  goal. 

C.4  The  Black  Box  Approach 

This  leaves  alternative  3.  In  this  approach  TCP  is  implemented  only  at 
gateway  nodes.  It  Is  here,  and  only  here,  where  the  execution  of  a  fully 
implemented  TCP  takes  place.  Each  Internetwork  message  Is  encapsulated  with  a  TCP 
header.  (This,  in  turn.  Is  encapsulated  with  an  IP  header,  an  outbound  local 
network  header  and  a  data  link  header  prior  to  transmission.)  The  only 
expectation  of  the  gateway  TCP  Is  that  a  predefined  set  of  interfaces  be 
provided.  These  Interfaces  (unlike  those  In  the  LNTCP)  are  not  dependent  upon  any 
specific  underlying  protocol. 

It  can  be  thought  of  as  a  “black  box"  approach.  Except  for  the 
gateways  the  LAN  has  no  knowledge  or  understanding  of  TCP.  From  a  system 
engineering  standpoint  this  Is  both  conceptually  and  practically  desirable. 
Drawbacks  of  this  alternative  are  the  Increased  complexity  of  the  gateway  node  and 
the  possibility  of  traffic  congestion. 

When  discussing  this  solution  there  is  frequently  a  failure  to  mention 
what  Interfaces  are  required  between  the  i_AN  local  nodes  end  the  LAN  gateway 
node.  These  Interfaces  must  1"clude  all  the  information  necessary  for  the 
creation  of  the  TCP  header  and  psuedo  header  which  is  not  an  Inherent  part  of  the 
protocol  mechanism  Itself.  Since  TCP  Is  a  connection  oriented  protocol. 

Interfaces  must  also  be  designed  to  permit  connection  establishment  and 
termination.  These  data  Items  Include:  source  and  destination  port  numbers,  the 
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32-bit  Internet  source  and  destination  addresses  (or  the  Information  necessary  to 
create  these  addresses),  specification  on  a  per  message  basis  of  control  bits  for 
urgent  and  push,  a  means  of  returning  to  the  source  node  tie  local  connection 
name,  and  a  means  of  forwarding  messages  received  at  the  gateway  to  the  local 
source  node. 

Two  possible  ways  to  provide  the  necessary  Interfaces  come  tc  mind.  In 
either  method  each  local  node  would  have  to  perform  a  test  on  each  outgoing 
message  to  determine  If  Its  final  destination  were  outside  the  net.  This  is 
necessary  because  the  source  node  must  Include  enough  Information  for  the  gateway 
node  to  establish  whether  or  not  the  received  message  Is  intended  for  Itself  or  Is 
co  be  forwarded  outside  the  net.  The  source  node  could  then  Include  all  the 
necessary  TCP  Information  within  Its  messages.  Alternatively,  the  gateway,  upon 
recognizing  a  message  destined  for  outside  the  network,  could  solicit  the  source 
node  for  any  required  parameters. 

C.5  Conclusions 

To  unconditionally  require  the. Implementation  of  TCP  within  all  LANs 
seems  inappropriate  from  hoth  an  operational  and  functional  standpoint.  The  best 
solution  appears  to  lie  in  a  "TCP  at  the  gateway"  app**oach  with  no  special 
underlying  LAN  protocol  required. 
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APPENDIX  0 

PROTOCOLS  IDENTIFIED  FOR  THE  GENERIC  NETWORK 
OPERATING  SYSTEM  (GNOS)  REFERENCE  MOOEl 
D.l  Introduction 

The  Generic  Network  Operating  System  (GNOS)  provides  a  reference  model 
for  viewing,  understanding  and  developing  protocols  needed  to  build  distributed 
processing  systems  for  c3l.  This  appendix  Identifies  protocols  required  for 
GNOS.  Figure  D.l  Is  an  architectural  Illustration  of  GNOS. 

D.l .1  Overview 

Message-based  Transaction  and  File  Transfer  protocols.  In  support  of 
software  program  functions,  comprise  the  Generic  Network-wide  Operating  System 
(GNOS).  Software  program  functions  perform  distributed  Resource  (Object) 
Management  operations  In  support  of  the  distributed  applications  (policy  setting/ 
execution  functions  reside  here)  by  way  of  Resource  Manager  protocols  and 
assessing  Networking  Utility  services. 

A  networking  protocol  suite  Is  comprised  of  three  service  regions: 

t  Networking-wide  Utilities  (canonical  form  of  hlgn  level  services 
for  accessing  remote  resources) 

•  Host  to  Host/Internet  data  transport  services 

•  Local /Wide  Area  Network  transmission  services 

Networking-wide  utilities  provide  generic  services  to  the  Resource 

(Object)  Manager  entitles  to  enable  remote  resource  access  to  Files,  Terminals, 
Data,  Jobs,  Messages,  etc.  The  combination  of  Resource  (Object)  Managers  and 
Networking-wide  Utilities  functions  comprises  the  General  distributed  Network 
Operating  System  (GNOS);  where  a  local  resource  Is  employed.  The  Resource  Manager 
accesses  It  using  Its  Constituent  Operating  System  (COS). 

0.2  GNOS  Protocols 

Protocols  are  needed  at  several  levels  to  enable  distributed  Object 
(Resource)  Managers  to  cooperate  autonomously.  The  levels  Identified  consist  of 
the  following: 

9  User  to  OSCRL* 

•  OSCRL  to  Resource  Managers 

•  Resource  Managers  to  Resource  Managers 

•  Networking  Utilities  to  Networking  Utilities 


*  OSCRL  -  Operating  System  Command  and  Response  Language  (GNOS) 
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•  Host  to  Host  Interprocess  communications 

-  Transport 

-  Internetwork 

•  Subnet  Transmission 

Local  Area  Network 
Hide  Area  Network 

0.2.1  Process  (Object)  to  Process  (Object)  Protocols 

Asynchronous  hanallng  of  simultaneous  process  to  process  transaction 
messages  Is  required.  Stream  Interprocess  communications  is  required  between 
cooperating  processes.  This  has  a  unl-alrectlonal  data  channel  session  type 
between  two  objects.  One  Is  a  data  source,  the  other  a  data  sink  and  connects 
processes  with  files,  devices,  and  other  processes. 

Transactions  will  be  the  primary  method  fo**  objects  to  communicate 
through  exchanging  messages;  however,  a  connection-oriented  service  will  be 
required  for  transferring  files. 

Message  exchange  characteristics: 

•  Intra-host  (local  only) 

•  Inter-host  (LAN  only,  LAN/ Internet/LAN) 

Message  types: 

•  Small,  minimal  effort  (datagram  service) 

•  Small,  reliable  (virtual  circuit  service) 

•  Large,  reliable  (virtual  circuit  service) 

Predominant  form  of  messages  exchanged  will  be  for  control.  These 
request  operations  to  be  performed  on  objects  (local /remote),  with  replies 
generated  by  performed  operations,  plus  exception  notices  and  messages  to 
coordinate  the  distributed  Object  Managers. 

0.2.2  Resource  (Object)  Manager  to  Resource  (Object)  Manager  Protocols 
The  following  Resource  (Object)  Managers  require  peer  protocols: 

•  Program 

•  Terminal  Manager 

•  Authorization/Access  Control /Security 

t  Catalog 

•  Device  I/O 

•  Network  Management 

•  Directory 

•  OSCRL 

•  File 
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•  Monitoring  and  Control 

•  Data  Base 

•  Host 


Object  Manager  to  Object  Manager  communications  employs  a  high  level 
form  of  protocol.  It  Is  asynchronous  and  Involves  handling  interleaved  messages 
from  possibly  several  processes.  Messages  are  received,  requests  are  originated 
to  satisfy  tiie  client  requests,  and  a  reply  message  sent  to  the  original  message. 
In  the  case  of  failure,  the  Object  Manager  assures  the  client  that  either  all 
changes  requested  will  take  place,  or  none  will  for  the  atomic  transaction 
performed.  Standardized  Object  Manager  to  Object  Manager  message  types  and 
structuring  Is  required  of  message  formats  employed. 

Resource  Managers  make  a  sat  of  resources  available  to  users 
(programs),  such  as  processor  cycles,  mein  storage,  files  on  disk  or  tape,  such 
I/O  devices  as  keyboards  or  displays,  and  such  abstract  resources  as  sessions, 
queues,  or  data  base  records.  Resource  Managers  allocate  resources  to  users  as 
its  central  function  In  response  to  a  user  request.  This  Includes  access 
scheduling,  coordination,  resource  allocation  deadlock  detection,  resource  change 
comnitment  control,  resource  access  security  and  resource  formatting  services. 
Resource  Managers  employ  resource  coordination  peer  protocols  and  access  network 
services  by  way  of  Interfacing  to  the  Network Ing-wlde  Utility  protocol  services. 
Program  to  Program  protocols  exchanged  between  Resource  Manager/Network  Utility 
entities  make  up  the  distributed  network  operating  system. 

Protocols  support  cooperation  among  the  distributed  Resource  Managers 
to  perform  the  following  activities: 


D.2.3 


Interprocess  communications 
Data  representation 

Data  storage  (media,  file  and  data  base) 
Process  management 
Resource  management 
Integrity  and  security 
Program  support 


Networking-Wide  Utility*  Protocols 


Network  Management 


Virtual  Terminal 


File  Access,  Transfer,  Management 


*  SupDorted  by  its  type  Presentation  and  Session  protocols. 
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•  Job  Transfer/Manipulation 

•  Message  Handling 

•  Document  Interchange 

•  Name  Server 

f  Data  Base  Access/Management 

D.2.4  Interprocess  Communications 

Interp-ocess  communications  facility  exhibits  a  loosely  coupled  message 
passing  characteristic  (not  memory  sharing) 

•  Transaction  (connection-less)  to  be  predominant  form  of  exchange 

•  Stream  (connection-oriented)  will  also  be  required 

D.2.5  Gateways  Elements  are  Required  for  Interoperability 

Intrasystem  and  Ir.tersystem  connectivity  functions  are  required  to  be 

performed. 
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APPENDIX  E 

NETWORKING  AND  SYSTEM  RESOURCE  MANAGEMENT 
IDENTIFIED  PROTOCOLS 

E.l  Introduction 

An  Important  aspect  of  Open  Systems  Interconnection  (OSI)  Is  the 
organization  of  the  distributed  processing  activity  and  the  resources  required  for 
its  successful  prosecution.  The  work  on  Application  and  Systems  Management,  and 
Job  Transfer  and  Manipulation  deals  with  the  specifics  of  distributed  processing 
activities.  This  appendix  identifies  management  protocols  required  and  some 
characterizations  of  their  functionality. 

E.2  OSI  Systems  Resource  Management 

This,  In  conjunction  with  Job  Transfer  and  Manipulation,  deals  with  the 
organization  of  Distributed  Processing  activity  and  the  resources  required  for  its 
successful  prosecution. 

Examples  of  OSI  Systems  Management  include: 

•  Regular  management  activities  for: 

-  Resource  allocation/deallocation 

-  Access  control 

Process  activation/deactivation 
Accounting 

•  Change  management 

-  Reconfiguration 
Name  handling 

•  Security  management 

-  Authentication 
Encryption 

•  Integrity  management 

-  Including  commitment  control 

•  Error  reporting,  recovering,  and  journaling 

E . 2 . 1  OSI  Management  -  Deals  with  Managing 

Application-Process-Group,  Systems  and  Layers  as  follows: 

1.  Application-Process-Group  Resource  Management 

Control  and  monitoring  of  an  Appllcation-Process-Group's 
activities 

Objects  being  managed  are  conceptual  views  of:  Files,  Data 
Bases,  Job  Processing  Resources,  etc. 

-  Functions  include  concurrency  control,  recovery,  accounting 
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.  Systems  Management 

-  Control  and  monitoring  of  the  NOS  networking  utilities 
resources  (OSI  resources) 

-  Functions  Include  resource  activation/deactivation,  allocation 
and  deallocation,  and  reconfiguration 

3.  Layer  Management 

-  The  control  and  monitoring  of  the  communication  resource 

E.2.2  Appllcatlons-Process-Group 

This  Is  a  collection  of  Information  processing  activities  (application 
processes)  which  collaborate  to  meet  a  specific  Information  processing  need. 

Within  the  OSI  layered  architecture,  this  Is  raanl'ested  as  a  related  group  of 
communication  activities  between  application  entitles. 

E.2.3  An  OSI  Resource 

This  Is  a  conceptual  view  of  a  class  of  actual  resources  that  may  be 
used  by  the  Appltcatlon-Process-Group  In  meeting  the  user's  Information  processing 
requirement.  Instances  of  OSI  resources  are  termed  management  objects. 

E.2.4  OSI  Management  Protocols 

These  constitute  the  rules  by  which  management  information  will  be 
exchanged  among  the  end  and  open  system  resource  managers.  The  OSI  management 
framework  has  been  divided  Into  two  key  concepts;  the  Appllcatlons-Process-Group 
and  the  OSI  resource. 

E.2.5  Some  Specific  Management  Standards  Topics  (Future  Work  Required) 

•  01  rectory  Information 

Names,  addresses  and  attributes  of  OSI  resources 

•  Accounting  management 

-  Information  on  charges  for  use  of  resources 

•  Authorization  management 

-  Information  about  management  authorization 

•  Commitment,  concurrency,  recovery 

-  Ensure  Integrity  of  information  processing  against  system 
malfunction 

•  Control  of  applicatlon-process-gmips 

Monitor  and  control  activity  for  enrol lment/de-enrollment, 
activation/deactivation.  Initiation/termination  of 
appl Icatlon-process-groups 
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E.3  Job  Transfer  and  Manipulation  (JTM) 

JTM  services  and  protocols  facilitate  Job  processing  In  distributed 
systems,  relating  not  only  to  the  movement  of  Job-related  data  between  open 
systems,  but  also  to  the  movement  of  Information  to  monitor  and  control  job 
processing  activity.  A  job  In  OSI  *s  described  In  terms  of  the  type  of  work  to  be 
carried  out. 

E.3.1  JTM  System 

Is  subdivided  Into  four  functional  components: 

•  Job  Submission  System  {Issues  demand  for  job) 

•  Job  Processing  System  (does  the  job) 

•  Job  Monitoring  System  (advises  on  job  progress) 

•  Job  Manipulation  Submission  System  (controls  the  JTM  activity) 

E.3.1 .1  JTM  Entities 

Communicate  through  the  transfer  of  work  specifications,  which  are 
structured  data  objects  that  define  all  the  work  which  the  recipient  is  required 
to  perform. 

E.3.1. 2  JTM  Work  Specification 

Consists  of  two  parts;  a  control  part  and  a  documents  part.  The 
control  part  contains  work  control  Information  and  are  subject  to  JTM  protocol 
standards.  The  documents  part  Is  transparent  to  JTM  and  conveys  recipient 
specific  Information.  JTM  acts  on  the  Information  In  the  control  part  but  passes 
the  documents  to  the  local  environment  (end  system). 

E.3.1. 3  Management  of  Appl icatlon-Process-Groups 

Both  OSI  Management  and  Job  Transfer  and  Manipulation  have  features 
which  are  common  and  relate  to  the  management  of  APG's.  On  the  one  hand,  OSI 
Management  deals  with  the  whole  of  distributed  management,  whereas  JTM  Is  dealing 
with  the  specific. 

E.4  Open  Systems  Management  Issues 

E.4.1  OSI  Management  Control  of  Application-Process-Groups 

This  deals  with  standardized  access  to,  and  use  of,  the  information 
processing  resource  and  the  protocols  to  initiate  and  monitor  the  activities  of  an 
APG  as  an  instance  of  an  OSI  resource  to  be  managed. 

E.4. 2  Job  Transfer  and  Manipulation 

This  environment  presupposes  existing  job  processors  to  which  work 
specifications  are  submitted  fcr  a  specific  piece  of  job  processing.  Separate 
subjobs  are  only  loosely  related  in  time,  and  the  structure  of  the  distributed  job 
does  not  rely  upon  the  prior  commitment  of  resources  to  accomplish  each  subjob. 
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£.4.3  General  Olstrlouted  Processing  Management 

This  activity  requires  considerably  more  generality  and  functionality 
than  currently  possessed  by  the  JTM  service.  A  uniform  Operating  System  Command 
and  Response  Language  (OSCRL)  has  been  Identified  for  the  general  model  of  system 
control  and  monitoring  functions  In  a  generalized  distributed  processing 
environment.  This  also  has  ramifications  on  work  under  way  for  programming 
languages  aimed  at  standardization  of  the  user's  language  Interface  with  a 
distributed  processing  activity.  It  is  essential  that  the  distributed  processing 
models  adopted  by  the  OSI,  OSCRL  and  Programming  Languages  groups  correspond  with 
each  other.  Failure  to  do  so  would  result  In  incompatible  multiple  standards  and 
their  accompanying  costs. 

E.4.4  Implications  of  Open  System  Interconnection 

Where  current  work  In  OSI  has  dealt  with  communications  protocols  for 
seven  layers  of  services,  the  Implications  of  OSI  extend  far  beyond  the  Instance 
of  just  open  comnunlcatlon.  Experts  are  now,  in  OSI,  viewing  how  the  OSI  layered 
approach  may  be  viewed  In  relation  to  the  full  scope  of  distributed  Information 
processing  and  not  just  communications.  It  has  been  proposed  In  ISO  to 
restructure  the  current  work  on  Programming  Languages,  OSCRL  and  communications 
Into  a  Global  OSI  project  spanning  Distributed  Information  Processing. 
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APPENDIX  F 

REMOTE  DATA  BASE  ACCESS  PROTOCOL 

F.l  Introduction 

A  set  of  protocols  Is  required  within  a  distributed  processing  system 
to  enable  remote  access  to  data  located  at  another  location  In  the  network. 

During  the  study,  two  works  reviewed  were  found  to  provide  a  framework  for 
structuring  the  development  of  suitable  protocols;  the  following  briefly  discusses 
these. 

F.2  Interconnecting  Heterogeneous  Data  Base  Management  System 

Reference  [98]  presents  a  discussion  on  the  analysis  of  the  existing 
approaches  to  Interconnecting  heterogeneous  Data  Base  Management  Systems  (DBMS) 
and  reviews  alternatives  from  four  experimental  projects.  An  architectural  model 
presented  Is  shown  In  Figure  F.2. 

The  functional  layering  of  the  network  of  heterogeneous  DBMS's,  which 
refers  only  to  the  application  layer  of  the  ISO  reference  model  described  by  the 
International  Standards  Organization,  consists  of  three  sublayers:  1)  the  Global 
Data  Manager,  or  GOM,  Is  the  top-most  sublayer  that  provides  services  directly  t.o 
the  end  user;  2)  the  Distributed  Transaction  Manager,  or  DTM,  Is  the  middle 
sublayer  that  supports  the  services  of  the  GDM  and  requires  the  services  of  the 
Structured-Data  Transfer  Protocols;  and  3)  the  Structured  Data  Transfer  P-otocols, 
or  SDTP,  Is  the  lower  sublayer  that  supports  the  services  of  the  DTM  and  requires 
the  services  of  the  Data  Presentation  Protocol,  or  DPP,  and  of  other  application 
layers,  such  as  those  of  the  File  Transfer  Protocol,  or  FTP. 

F.2.1  Global  Data  Manager 

The  Global  Data  Manager  (GDM)  of  a  distributed  DBMS  performs  both  the 
mapping  between  the  global  unified  view  of  the  data  and  the  local  DEMS's,  and  all 
relevant  I/O  operations.  The  following  five  functions  are  Included  In  the  GDM: 

1.  Global  data  model  analysis 

2.  Query  decomposition 

3.  Query  translation 

4.  Executing  plan  generation 

5.  Results  Integration 

F.2.2  Distributed  Transaction  Manager 

The  Distributed  Transaction  Manager  (DTM)  Is  responsible  for 
controlling  the  execution  of  distributed  transactions  in  integrated  distributed 
DBMS's;  those  transactions  will  reference  data  at  more  than  one  site  In  a 
network.  A  primary  purpose  of  a  transaction  manager,  whether  it  Is  distributed  or 
centralized,  is  to  help  ensure  the  consistency  of  the  data  base.  To  do  this,  the 


2122D/IAN 


F-l 


T-  '  • 

iVv*- 


GLOBAL 

DATA 

MANAGEMENT 


DimUfUTTD 

TRANSACTION 

MANAGEMENT 


STRUCTURED 

DATA 

TRANSFER 

PROTOCOLS 


DATA 

communicatiop 

PROTOCOLS 


Cl  OWL  QUERY  FORMULATION 
C4IFORM  GUtRY  LANGUAGE 
GLOBAL  SCHEMA 


GLOBAL  QUERY  TRANSLATION 
AM  DECOMPOSITION 


GLOBAL-LOCAL  SURCSJCRT  MAPPWB 
•TRANSLATION)  CL05AL-10CAL 
SCHEMA  CAPPING!  {TRANSLA¬ 
TE  N)  RESOURCE  MANAGEMENT 
RESULTS  INTEGRATION 


EXFCUTlOi  PU»  SEREUTICI 

LOCAL  TRANSACTION  COORDINATION  I 


INTERACTION  WITH  LOCAL  DBMS  a 


LOCAL-RESOURCE  C00R01RATU3R 
{INTERFACE  WITH  DATA  MANAGERS) 


ASSEMBLY  OP  INDIVIDUAL  RESULTS  I  | 

_ _ Lj 

[  COMMABD  TRANSFER  PROTOCOLS  J  I 

;  f  * 

[  STRUCTURE  TRANSFER  PROTOCOLS  I  I 


TYPE  AND  FORMAT  g 

TRANSLATION  PROTOCOLS  |  ^ 


r  FILE  TRANSFER  PROTOCOL 

DATA  PRESENTATION  PHOTOCOl  NETWORK 
I  INTERPROCESS  COMMUNICATION  PROTOCOL 


Figure  F.2.  Archl tectural  Protocol  Model  for  Heterogeneous  DBMS 


2122D/LAN 


*  j.  •  j.  •_»  *4-  ■. 

.  •  .**  .*»  .*  .  •  .*•  »**  -  *  •** .  *  v  *,•  *, 

y  --v-v-v-v* v-v-v-v 


s  *B*  ’  j 


V! 


*.  ■  %  v; 

k' m\mW, 


V 

V>\ 

\/.v 
v  , 

t  ---.»• 


OTM  assumes  that  whenever  a  transaction  runs  In  Isolation  and  completes  Its  task. 
It  preserves  the  consistency  of  the  data  base.  Concurrency  control  schedules  the 
subtransactions  of  concurrently  operating  transactions.  Recovery  control  provides 
data  protection  and  recovery  procedures  for  all  transactions. 

F.2.3  Structured  beta  Transfer  Protocols 

The  Structured  Data  Transfer  Protocols  (SDTP's)  are  application-level 
(Layer  7)  protocols  required  for  the  Interconnection  of  remote  heterogeneous 
DBMS's.  The  SDTP's  are  used  by  protocols  and  programs  at  higher  levels  which 
implement  the  Interconnection  of  the  reujte  DBMS's.  These  protocols  and  programs 
belong  to  the  GDM  and  to  the  DTM.  The  SDTP's  themselves  use  the  data 
communication  protocols.  The  areas  covered  by  the  SDTP's  are  the  following: 

1.  Corwnana  Transfer  Protocols 

2.  Structure  Transfer  Protocols 

3.  Type  and  Formal  Transaction  Extension  to  a  Data  Presentations 
Protocol 

F.2.3. 1  Comnianq  Transfer  Protocols 

The  Command  Transfer  Protocols  deal  with  the  transfer  of  commands  to 
remote  DBMS's.  These  protocols  are  particularly  useful  In  cases  where  some  of  the 
transaction  and  data  management  protocols  are  Implemented  as  remotely  located 
se-vers,  rathe:  than  as  application-protocol  layers.  As  with  other  SDTP's,  the 
Command  Transfer  Protocols  use  a  canonical  command  format  for  command  transfer 
across  the  network.  Higher  levels,  such  as  the  GDM,  will  perform  the  translation 
between  local  command  formats  and  the  cononical  form. 

F.2.3.?  Structure  Transfer  Protocols 

The  most  important  SDTP's  are  the  Structure  Transfer  Protocols.  A 
structure  can  be  a  Pascal  or  a  Coool  record,  a  PL/1,  or  a  C  structure.  The 
Structure  Transfer  Protocols  Include  two  basic  kinds  of  protocols:  1)  protocols 
for  structures  with  pointers,  and  2)  protocols  for  pointer-free  structures.  The 
STP  is  a  direct  user  of  the  File  Transfer  Protocol  and  Data  Presentation  Protocol 
layers  since  files  are  most  likely  to  be  the  representation  type  for  most 
structuies  with  or  without  pointers. 

F . 2 . 3 . 3  Type  and  Format  Translation  Protocols 

Type  and  Format  Translation  Protocols  are  necessary  for  types  of 
objects  not  Included  at  the  DPP  level.  The  Structured  Transfer  Protocols  require 
that  the  DPP  level  must  be  extensible,  that  is,  the  DPP  must  be  prepared  to  handle 
a  large  variety  of  types  in  addition  to  four  currently  specified. 

Reference  [38]  discusses  functions  of  the  SDTP  protocols  In  more  depth. 
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Remote  Data  Base  Access  Protocol  of  ECMA 


F.3 

F.3.1  General 

The  European  Computer  Manufacturers'  Association  (ECMA)  Standards 
Organisation  has  developed  a  draft  Remote  Data  Base  Access  Protocol  [99].  This 
was  deemed  by  the  study  to  represent  a  major  contribution.  The  principal  stated 
characteristics  of  this  protocol  are  that: 

1.  It  offers  efficient  remote  access  co  data  base 

2.  It  supports  a  distributed  data  base 

It  provides  a  general  framework  for  remote  access  to  data  bases  of  many  types, 
with  specific  encodings  for  access  using  the  Relational  Model. 

The  protocol  standard  is  one  of  a  set  of  standards  for  Open  Systems 
Interconnection.  It  Is  intended  to  facilitate  homogeneous  Interworking  between 
heterogeneous  information  processing  systems.  It  Is  consistent  with  emerging  data 
base  standards  being  created  by  ANSI  X3H2,  and  capable  of  modular  extension  to 
cover  future  needs  and  to  exploit  future  developments  in  technology. 

The  Standard  for  the  Remote  Data  Access  Protocol : 

•  Defines  a  data  base  model 

•  Defines  the  operations  on  the  data  base  model  as  abstract 
Interactions  between  two  users  of  the  communications  service,  cne 
of  which  Is  acting  on  behilf  of  an  application  program  while  the 
other  Is  Interfacing  to  a  process  that  controls  data  transfers  to 
and  from  the  data  base 

•  Defines  the  protocol  to  support  the  above  service  and  Its  mapping 
to  the  underlying  presentation  service 

•  Specifies  the  requirements  for  conformance  with  this  protocol 
The  protocol  Is  targeted  at  data  base  systems  that  support  the 

relational  model.  However,  It  Is  envisaged  that  other  data  base  systems  will 
support  relational  interfaces  and  that  sunsets  or  supersets  of  the  protocol  may  be 
used  with  other  data  base  systems. 

This  protocol  is  for  the  Application  Layer  of  Open  Systems 
Interconnection. 

F.3. 2  Data  Base 

This  section  describes  the  characteristics  of  a  data  base  that  are 
assumed  by  the  model  and  Identifies  specifically  those  that  are  visible  to  remote 
users  of  the  data  base.  The  DBMS  consists  of  all  the  compilers,  utilities  and 
data  base  access  software  necessary  to  support  the  creation,  management  and  use  of 
the  data  base.  The  term  Data  Base  Control  System  (DBCS)  specifically  refers  to 
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run-time  component  providing  date  base  access  and  manipulation  facilities  to 
application  programs. 

F.3.2.1  The  Data  Base  and  Distributed  Data  Base  Models 
F. 3. 2. 1.1  General  Principles 

A  data  base  Is  a  coordinated  body  of  data  managed  by  a  software  entity 
termed  a  Data  Base  Management  System  (DBMS).  The  DBMS  maintains  the  data  base  In 
permanent  storage.  It  controls  and  facilitates  the  storage  and  retrieval  of  data 
In  the  data  base. 

A  logical  structure  of  the  data  base  Is  defined  by  a  data  base 
description  known  as  a  Schema.  This  defines  the  names  and  characteristics  of  all 
the  data  elements  that  may  be  stored,  the  Interrelationships  among  data  elements, 
and  the  constraints  on  the  values  they  may  take.  Details  of  the  mapping  of  data 
to  storage  and  performance  requirements  are  generally  defined  In  the  Internal 
Schema  or  Storage  Schema  so  that  the  logical  capabilities  that  are  visible  to 
programmers  can  be  separated  from  the  performance  concerns  which  are  the 
responsibility  of  a  data  administrator. 

Access  to  the  data  base  by  application  programs  may  be  via  a  procedural 
interface  or  by  extensions  to  a  Programming  Language  which  we  can  Imagine  being 
compiled  into  code  that  invokes  the  same  procedural  Interface.  Sines  different 
application  programs  require  access  to  different  subsets  of  the  data  base  the  data 
available  at  the  procedural  Interface  for  any  single  connection  Is  defined  In  a 
separate  data  definition:  the  Subschema  or  External  Schema.  The  procedural 
interface  specification  defines  the  data  manipulation  functions  available  and 
their  effects  on  the  data  base. 

Specifications  of  the  data  structure  descriptions  and  the  data 
manipulation  functions  have  been  developed  by  ANSI  X3H2.  The  semantics  of  the 
functions  described  in  this  specification  and  their  effects  upon  the  data  base  are 
defined  in  that  document. 

The  current  ANSI  ROL  does  not  include  a  Subschema.  However,  the 
subschema  required  by  this  protocol  may  be  identified  to  the  RDL  schema  so  there 
is  no  conflict.  Also,  the  subschema  Invoked  in  RDA  may  be  a  relational  data  base 
description  which  an  implementor  has  provided  for  nonrelational  data  bases. 

F. 3. 2. 1.2  Remote  Access  to  a  Data  Base 

Figure  F.3.2.1.2  shows  the  structure  for  remote  data  base  access. 

The  client  process  is  an  application  program  or  Query  Language 
Processor  that  has  a  data  processing  job  to  do.  The  Application  Layer  entitles 
are  software  components  that  handle  the  communications  cn  behalf  of  the  client 
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Figure  F. 3. 2. 1.2.  Structure  of  Remote  Data  Access 

process  and  the  server  process.  At  the  data  base  end,  the  server  process  Is 
translating  the  protocol  messages  Into  Data  Manipulation  Procedural  Interface 
calls  and  parameters  and  transmitting  the  results  back  using  the  service 
primitives. 

The  diagram  does  not  show  the  structure  of  the  client  process. 

However,  It  Is  envisaged  that  the  service  Interface  on  the  client  side  will 
generally  he  driven  by  a  component  of  a  DBMS  {or  distributed  DBMS)  so  that  the 
user  Interface  for  remote  access  to  data  Is  rot  unnecessarily  different  from  the 
interface  used  when  data  is  local. 

F. 3. 2. 1.3  A  Distributed  Data  Base  or  Multi-Data  Base  System 

A  distributed  data  bass  is  a  coordinated  body  of  data  that  Is 
partitioned  Into  separated  data  bases,  each  managed  by  its  own  DBMS.  Coordination 
across  the  components  is  managed  by  a  distributed  DBMS  (DDBMS)  which  is  itself 
distributed. 

It  is  possible  for  a  client  process  (or  application  program)  to  access 
the  distributed  data  base  without  being  knowledgeable  about  the  location  of  the 
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data  elements.  Figure  F. 3. 2. 1.3-1  shows  .a  client  process  calling  a  DDBMS 
component  In  Its  own  end  system  which  communicates  with  peer  entitles  (DDBMS 
components)  In  other  end  systems  via  the  DDBMS  connections. 

Each  connection  between  DDBMS  components  Is  an  OSI  Application  1ayer 
connection.  The  transport  connections  will  handle  many  transactions 
simultaneously,  but  the  protocol  defined  in  this  document  is  concerned  with  the 
Interaction  between  the  site  with  the  client  process  and  one  other  site.  Figure 
F. 3. 2. 1.3-2  shows  the  structure  of  a  single  connection. 

F.3,3  Protocol  Characteristics  Summary 

The  Remote  Data  Base  Access  Protocol  document  addresses  the  following 
characteristics: 

1.  Service  Description 

a.  Roles  of  Partners 

b.  Dynamic  Structuring  of  an  RDA  Connection 

c.  Connection  Services 

d.  Subschema  Management  Services 

e.  Data  Manipulation  Definition  Services 

f.  Transactions 

g.  Data  Manipulation  Functions 

h.  Bulk  Data  Transfer 

2.  Protocol  Specification 

a.  Connection  Management 

b.  Transaction  Management 

c.  Grouping  of  Statements 

d.  Bulk  Data  Transfer 

e.  RDL  Statements  and  Macros 

3.  Conformance 
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APPENDIX  G 

GENERIC  GATEWAYS  FOR  LAN  INTEROPERABILITY 
G.1  Introduction 

Gateways  are  functions  which  join  two  networks  together.  A  gateway  may 
look  to  each  network  like  one  of  its  own  nodes;  on  the  other  hand,  a  special 
purpose  function  node  may  be  specified.  A  gateway  comprises  the  collection  of 
hardware  and  software  required  to  effect  the  Interconnection  of  two  or  more 
networks  enabling  the  passage  of  user  data  from  one  to  the  other. 

G.2  Generic  Gateway  Family 

Gateways  are  utilized  to  achieve  Internetworking.  Here, 

Internetworking  refers  generally  to  the  Interconnection  of  networks,  whether 
similar  or  dissimilar.  Where  Internetworking  is  accomplished  at  a  given  layer  of 
the  OSI/RM,  generally  then  requires  any  two  applications  Layer  7  users  who 
actually  wish  to  communicate  and  Interoperate  must  choose  and  employ  common 
protocols  for  the  layers  above  where  Internetworking  Is  performed  and  up  through 
Layer  7.  If  this  Is  not  done,  then  one  must  find  and  employ  a  resource  to  perform 
protocol  conversion  functions  between  the  two  noncompatible  protocol  suites. 

The  solution  to  the  interconnection  of  different  types  of  local 
networks,  and  the  connection  of  local  networks  to  long-haul  networks.  Is  the  use 
of  high-performance  networking  gateways  and  bridges.  A  gateway  server 
traditionally  operates  between  two  similar  or  dissimilar  networks  and  can 
communicate  with  the  system  elements  or  nodes  on  each  of  the  adjacent  networks.  A 
gateway  also  performs  routing  or  protocol  translation  functions  that  allow  some 
level  of  Internetwork  communication  among  system  elements.  Gateways  are  naturally 
balanced  systems,  each  Implementing  two  half-gateway  functions,  plus  a  common 
relay  operation  to  join  the  two  halves  together. 

A  family  of  generic  gateways  is  needed  to  span  the  full  range  of  the 
OSI/RM's  seven  layers.  Table  G.2  lists  the  generic  gateway  set.  Each  Is 
discussed  In  the  following  paragraphs. 

G.2.1  Amplifier  Gateway  (Layer  0) 

This  type  of  gateway  Is  utilized  to  extend  the  length  of  a  media 
segment  employed  In  a  LAN.  It  is  a  linear  device  which  amplifies  the  received 
signals  and  may  compensate  for  Impairments  experienced  by  the  signal  received 
prior  to  retransmission.  This  operates  on  the  composite  signalling  bit  symbols 
contained  within  the  bandwidth  capacity  of  the  two  media  being  interconnected. 

This  can  be  either  uni  direction^  or  bidirectional .  Higher  layer  protocols  are 
transparent  to  the  effects  of  this  gateway. 
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Table  G.2.  6ener1c  Gateway  Types 


Gateway  Type 

OSI/RM  Layer(s) 

• 

Open  Systems  Interconnection 

7-0 

• 

Protocol  Conversion 

7-4 

• 

Internet 

3-0 

• 

Network  Relay 

3-0 

• 

Brl dge 

2-0 

• 

Repeater 

1-0 

• 

Channel  Translator 

0 

• 

Amplifier 

0 

Channel 

1  Translator  (Layer  0) 

This  type  of  gateway  Is  utilized  to  connect  the  frequency  of  one  LAN 
channel  to  a  different  frequency  of  another  LAN  channel.  This  Is  a  linear  device 
which  performs  a  frequency  shifting  (up  or  down)  and  may  amplify  and  compensate 
the  signal  present  on  the  medium  employed.  This  Is  analogous  to  the  Amplifier 
Gateway  In  that  Tt  extends  the  length  of  the  LAN.  This  gateway  may  be  statically 
configured  or  dynamically  swltchable  to  different  channel  frequencies.  Except  for 
address  assignments  associated  with  the  channel  Identifications,  all  higher  layer 
protocols  are  transparent  to  the  effects  of  this  gateway. 

G.2.3  Repeater  Gateway  (Layer  1-0) 

This  type  of  gateway  Is  utilized  to  extend  the  length  of  a  LAN's 
physical  topology.  It  Is  a  nonlinear  digital  device  and  converts  the  received 
digital  bit  stream  Into  a  reshaped  and  regenerated  outgoing  bit  stream.  The 
underlying  media  and  signalling  methods  may  be  the  same  or  different.  This  may  be 
employed  to  Interconnect  two  In-house  metallic  cable  based  LAN  media  by  way  of  a 
fiber-optic  iredlum  running  outside  and  between  the  locations  or  any  two  remote 
locations  by  way  of  a  leased  point-to-point  circuit  employing  modems.  Appropriate 
control  signals  may  need  to  be  extended  between  the  two  sites.  Higher  layer 
protocols  are  transparent  to  the  effects  of  this  gateway  and  it  differs  from  the 
Bridge  Gateway  In  that  the  Repeater  Gateway  stores  and  forwards  bits,  not  packet 
frames  or  packet  messages. 

G.2.4  Bridge  Gateway  (Layers  2-0) 

This  type  of  gateway  Is  a  packet  frame  store  and  forward  device  which 
Is  utilized  to  join  LAN  segments  together  containing  either  the  same  or  different 
MAC  protocols  (l.e.,  CSMA/CD  to/from  Token  Bus  Medium  Access  Control).  This 
contains  two  half-gateway  MAC'S  plus  a  relay  function  which  joins  the  two  halves 
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together.  All  of  the  normal  MAC  receive  de-encapsulation  functions  must  be 
performed  (l.e.,  framing,  error  detection,  address  recognition,  and  the  particular 
protocol’s  control  functions).  Then  the  relay  function  may  perform  a  filtering 
function  to  only  pass  on  frames  containing  addressed  data  destined  for  a  station 
on  or  beyond  the  next  LAN's  MAC  segment  being  Interconnected.  Selected  addressed 
frames  are  then  encapsulated  with  the  structure  of  the  new  LAN's  MAC  protocol 
structure  and  when  appropriate  is  transmitted. 

Since  all  of  the  IEEE  802  MAC  protocols  operate  in  the  connectionless 
service  mode,  each  MAC  frame  processed  Is  treated  as  a  separate  entity.  Whether 
the  next  sublayer  ( LLC )  Is  providing  connectionless  or  connection-oriented 
service,  the  Bridge  Gateway  appears  transparent  to  the  LLC  packet  frames.  The  LLC 
originating  and  destination  stations  manage  their  respective  state(less)  and  data 
management  functions  on  a  LAN  end-to-end  basis,  just  as  If  the  Bridge  Gateway  was 
not  present.  For  those  cases  where  the  two  MAC  protocols  joined  at  the  gateway  do 
not  provide  equivalent  services,  then  either  functionality  must  be  added  to  the 
protocol  of  lesser  equivalence  or  the  most  common  set  of  equivalent  services  Is 
used  to  form  the  service  basis  for  Interoperability  (l.e.,  the  higher  grade  of 
service  Is  subsetted  down  to  the  lower's  equivalence). 

This  type  of  gateway  Is  used  to  extend  the  range  and  overall  capacity 
of  the  original  LAN(s)  employed.  Higher  layer  protocols  can  be  made  transparent 
to  the  effects  of  this  gateway  when  a  proper  set  of  equivalent  services  Is 
achieved  and  used  in  the  Interconnection  mode. 

A  higher  layer  version  can  also  be  employed  by  a  Bridge  Gateway.  Here, 
the  gateway  terminates  the  MAC  and  LLC  services  of  one  LAN,  and  performs  a  pure 
relaying  operation  to  extend  this  LAN's  LLC  services  onto  the  next  LAN's  LLC 
protocol  sublayer.  This  Is  a  form  of  cascading  like  protocol  services  In  a  serial 
string  arrangement.  With  connectionless  LLC  service,  Inalvldual  LLC  frames  are 
passed  transparently  by  the  relay  to  the  next  LLC  protocol  entity.  However,  for 
connection-oriented  LlC  service,  each  LLC  logical  link  terminates  at  the  receive 
half  of  the  gateway,  the  Information  field  Is  then  relayed  Into  a  link  connection 
of  the  next  LAN's  LLC  entity,  and  a  new  set  of  statlon-to-statlcn  state  variables 
Is  established  for  each  succeeding  LAN  In  the  cascade.  Flow  control,  sequencing 
and  recovery  would  span  at  most  a  single  LAN  at  a  time,  since  LLC  Is  not  a  global 
end-to-end  protocol,  but  rather  a  single  LAN's  span.  This  LLC  relay  form  of 
Bridge  Gateway  would  avoid  the  use  of  a  separate  Internet  Protocol  above  the  LLC 
sublayer  as  Is  employed  in  the  Internet  Gateway  and  can  be  employed  where  each 
underlying  MAC  protocol  entity,  media  and  topology  elements  differ. 
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6.2.5  Network  Relay  Gateway  (Layers  3-0) 

This  type  of  gateway  Is  Intended  for  use  In  Interconnecting  a  LAM  to  a 
WAN  and/or  a  WAN  to  another  WAN,  without  having  to  employ  an  Internet  Protocol 
sublayer  above  It  (see  Internet  Gateway  below).  In  the  case  of  Interconnecting 
two  X.25  packet  switched  Public  Data  networks  together,  the  CCITT  X.75/X.121 
combination  of  recommendations  perform  this  Network  Relay  type  of  Gateway 
operation.  There,  X.75  performs  a  relaying  operation  where  origin  network  X.25 
virtual  circuit  connections  are  mapped  onto  new  X.25  virtual  circuit  connections 
of  the  destination  network  In  accordance  with  cascading  principles.  There  may  be 
three  or  more  state-dependent  virtual  circuits  pluggeo  Into  a  series  arrangement 
of  an  end-to-end  basis. 

A  proposal  [57]  made  by  the  author  In  1980  to  develop  a  gateway 
standard  approach  for  Interconnecting  IEEE  .  LAN's  by  way  of  X.25  WAN's  has  been 
translated  by  H.  C.  Folts  Into  a  pragmatic  approach  [68]  based  upon  the  Network 
Relay  Gateway  architecture.  In  this  approach,  an  X.25  Network  layer  set  of 
protocol  functions  Is  added  on  top  of  the  IEEE  802  suite  of  LLC,  MAC,  protocol 
layers  and  relayed  onto  the  X.25  Network  layer  used  to  access  a  wide  area 
network.  There,  the  X.25  Network  layers  employed  In  the  802  LAN's  as  well  as  the 
X.25  WAN(s)  would  each  operate  In  the  connectlon-orldnted  service  mode  on  an 
end-to-end  cascaded  basis  (like  the  way  X.25  -  X.75  -  X.25  networks  do  In 
series).  Above  Layer  3  an  appropriate  Layer  and  Transport  protocol  would  be 
employed. 

t  ■  •  * 

6.2.6  Internet  Gateway  (Layers  3-0) 

This  type  of  gateway  Is  employed  to  create  a  new  global  network  out  of 
the  Interconnection  of  otherwise  heterogeneous  LAN  and  WAN  subnetworks.  An 
Internet-working  sublayer  protocol  is  Incorporated  In  each  source  and  destination 
station  plus  the  gateway  nodes  which  join  a  LAN  to  WAN.  Generally,  connectionless 
operation  Is  employed  to  do  the  functions  of  end-to-end  packet  routing,  switching 
and  fragmentation-reassembly  of  packets  which  are  too  large  for  a  subnet.  The 
Department  of  Defense  Internet  Protocol  (IP)  is  the  best  example  of  this  gateway 
approach.  Within  each  gateway,  a  relaying,  routing  and  switching  operation  Is 
performed  on  the  control  information  contained  in  each  packet  header.  The 
Internet  Gateway,  employing  a  connectionless  protocol.  Is  a  more  general  and 
robust  solution  to  Internetworking  than  the  above  discussed  Network  Relay  Gateway, 
In  that  It  can  accommodate  a  heterogeneous  mix  of  subnets,  each  being  either 
connectionless  or  connection-oriented. 
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G.2.7  Protocol  Conversion  Gateway  (-layers  7-4) 

This  type  of  gateway  is  usea  to  Interconnect  networks  that  have 
different  protocol  architectures  (i.e.,  IBM's  SNA  with  DEC'S  DNA).  Basically, 
this  might  span  any  range  of  protocol  layers,  but  It  is  at  the  upper  layers  where 
the  greatest  differences  are  expected  to  occur  from  the  variations  In  proprietary 
solutions  being  offered  in  the  marketplace.  Proprietary  vendor  protocols  have 
been  developed  to  structure  the  internal  architecture  of  a  system,  this  being  a 
closed  rather  than  an  open  form  of  end  system,  which  the  OSI/RM's  protocol  suite 
has  been  defined  to  interconnect.  Therefore,  the  Protocol  Conversion  Gateway  has 
to  be  structured  with  protocols  from  the  two  proprietary  networks  attempting  to  oe 
interconnected.  Further,  a  place  up  in  the  higher  protocol  layers  must  be  found 
where  the  equivalence  of  services  either  exists  naturally,  or  by  functional 
enhancement/de-enhancement  can  be  made  to  be  equivalent  in  semantics.  Thereafter, 
translation  of  syntax  formatting  of  the  control  primitives  and  informatlor. 
representation  has  to  be  performed  to  map  between  the  two  protocols.  Most  likely, 
this  will  need  to  be  performed  at  or  above  the  Presentation  Layer.  In  addition, 
mapping  may  be  necessary  between  the  two  networks'  resource  management  protocols 
as  well. 

The  Protocol  Conversion  Gateway  Is  the  least  likely  one  to  ever  become 
standardized,  because  for  every  combination  of  vendor  network  to  be 
interconnected,  there  is  a  different  design  which  this  type  of  gateway  has.  Where 
implemented,  it  is  desired  to  do  this  only  once  In  a  gateway  node  which  joins  the 
two  networks  together.  When  two  protocols  are  not  "connectable,"  the  only 
possible  solution  for  communicating  with  the  other  entity  Is  actually  to  Implement 
the  other  entity's  protocol. 

G.2.8  Open  Systems  Interconnection  Gateway  (Layers  7-0) 

This  type  of  gateway  enables  the  Interconnection  and  interoperability 
of  otherwise  closed  (proprietary  architecture/protocol)  end  systems  by  forming  an 
open  global  system  of  systems.  The  OSI/RM  provides  the  international 
architectural  agreement  on  the  structure  of  protocols  and  their  rules  of  operation 
to  enable  open  systems  cooperation.  An  end  system  which  obeys  applicable  OSI 
standards  In  Its  cooperation  with  other  systems  Is  termed  an  open  system  (Figure 
G.2.8-1  and  G. 2.8-2). 

From  a  using  end  system's  perspective,  the  OSI  provides  an  end  system 
to  end  system  set  of  virtual  resource  management  protocols  (for  accessing 
terminals,  processes,  files,  jobs,  messages,  documents,  data,  OSI  resources)  as 
well  as  how  to  communicate  data  through  a  concatenation  of  LAN's  and  WAN's  via 
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Figure  G.2.8-2.  New  Distributed  Processing  Architecture 
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gateways.  The  OSI  protocols  only  deal  with  the  exchange  of  information  between 
and  systems  and  not  with  the  internal  functioning  of  each  system. 

The  application  of  the  OSI/RM  with  its  suite  of  protocols  will  foster 
the  use  of  universally  agreed-upon  means  of  permitting  communication  and 
cooperation  between  (or  among)  heterogeneous  systems  and  products.  Existing 
systems  will  progressively  implement  OSI  capability  in  response  to  user 
application  needs.  This  will  lead  to  Increasing  diversity  of  heterogeneous  open 
systems;  heterogeneous  because  they  are  built  on  different  architectures;  and  open 
because  they  are  capable  of  cooperating  with  other  systems  by  Implementing  the  OSI 
protocols. 

S.3  References 


The  references  applicable  to  the  work  discussed  above  are  [62-69]. 
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APPENDIX  H 

MULTIMEDIA  LAN  (MMLAN)  INTERNETWORKING 
H.I  System  Concept  -  MMLAN 

This  discusses  a  preliminary  system  baseline  concept  for  the 
integration  of  the  FILAN  witn  a  possible  MMLAN.  This  is  illustrated  In  Figure 
H.I,  which  depicts  a  hypothetical  distributed  command  center. 

Current  tactical  nodal  centers  of  the  Air  Force  are  highly  centralized 
and  therefore  are  vulnerable  to  eneoy  attempts  at  destruction.  This  threat  along 
with  new  LAN  and  distributed  system  technologies  will  permit  distributing  the 
resources  of  a  centralized  nodal  center  outward  among  Interconnected  shelters  and 
vans.  The  FILAN  can  provide  the  communication  facilities  for  use  within  each 
shelter  while  the  MMLAN  can  Interconnect  together,  with  multiple  serviceable 
1  i rises ,  the  collection  of  shelters  to  form  an  integrated  operation  center. 

In  Figure  H.I,  a  gateway  node  Is  Intended  to  interconnect  Individual 
FILAN  Local  Subnets  to  the  multiple  media  links  which  span  between  the  FILANs. 

The  gateway  would  function  as  a  Network  Access  Unit  (NAU)  on  the  FILAN  to  which  It 
belongs  as  well  as  be  a  user  of  each  data  link  provIdeG  by  the  MMLAN. 

Functionally,  the  gateway  would  incorporate  protocols  of  the  physical,  data  link 
and  internetworking  layers  associated  with  FILAN  and  the  COD  Internet  Protocol 
suite  on  the  FILAN  side,  and  individual  media,  physical  and  link  protocols  from 
the  new  MMLAN  suite.  A  collection  of  Network  Management  functions  and  protocols 
would  also  be  a  part  of  each  gateway  with  a  close  operational  tie  to  tech  FILAN 
Network  Management  node. 

Within  the  WLAN  subsystem's  sphehe,  there  woulo  be  employed  a  mixture 
of  terrestrial,  airborne  and  free-space  data  link  transmission  facilities.  These 
would  be  configured  to  satisfy  the  specific  constraints  of  the  particular 
deployment  In  such  a  way  to  ensure  survivability  In  the  event  any  data  link,  FILAN 
subsystems  or  both  were  destroyea.  Currently  envisioned  examples  of  meala  types 
for  potential  use  are  as  follows: 

1.  Fiberoptic1 

2. ’  Microwave  radio1 

3.  Spread  spectrum  data  links  with  a  remote  pilotless  vehicular  node 
(airborne)2 

4.  Millimeter  wave  radio2 

* Denotes  near  time  frame. 

2 

Denotes  longer  term. 
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5.  Infra  red  rad1o2 

6.  Packet  radio2 

7.  Terrestrlall 

8.  JTI0S2 

Of  all  these  media  types,  the  concept  of  employing  a  terrestrial 
satellite  (based  upon  an  overhead  circling  RPV  node  employing  spread  spectrum 
techniques)  appears  to  be  well  suited  to  providing  full  connectivity  among 
distributed  nodal  shelters.  Such  a  configuration  appears  to  be  well  suited  to  the 
objective  of  achieving  a  distributed,  survival  command  center  to  counter  foreseen 
tactical  threats.  Harris  Corporation  has  conducted  studies  in  the  use  of  the 
MICNS  RPV  data  link  system  to  perform  such  a  mission  and  has  documented  a  systems 
design  approach  in  a  classified  report.  On  the  other  har.a,  low  cost  packet  radio 
appears  to  be  another  viable  alternative  for  consideration.  The  technology  has 
been  demonstrated  by  experiments  conducted  by  the  army  at  Ft.  Bragg  employing 
elements  of  the  TCP/IP  Internet  Protocol  suite.  Two  other  media  appear  to  offer 
substantial  benefits  in  their  own  right;  fiber  optic  cable  and  millimeter  wave 
radio.  The  costs  and  performance  capabilities  of  these  will  have  to  be  examined 
further.  In  any  real  system  deployment  of  the  MMLAN,  no  single  media  would  be 
relied  upon  exclusively  to  ensure  survivable  communications.  The  system  design 
would  be  structured  to  be  able  to  mix  and  match  any  of  the  selected  media  types 
then  exercise  operational  systems  control  to  maintain  the  minimum  essential  degree 
of  availability  specified  for  the  mission. 

Harris  Corporation  is  currently  under  contract  [100]  studying  the 
application  of  LAN  and  multimedia  for  a  MMLAN  system  definition. 
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